Announcement

Collapse
No announcement yet.

KDE Introduces KCommandBar For HUD-Style Popups

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

  • tildearrow
    replied
    Originally posted by 144Hz View Post
    KDE should end the WM dictatorship (SSD only ) and start listening to the users, devs and designers who request better decorations (SSD+CSD)
    GNOME should end the WM dictatorship (CSD only on Wayland) and start listening to the users, devs and designers who request better decorations (SSD+CSD)

    Leave a comment:


  • geearf
    replied
    That looks awesome! Thanks guys!

    Leave a comment:


  • Mavman
    replied
    Originally posted by skeevy420 View Post
    That's pretty neat and being able to search what a program can do like that looks to be very damn useful. The only thing I didn't catch was the key combo to fire it up.
    In KATE you can use Ctrl+Alt+I and you'll get to Open Command Bar.
    In Krita - where it would be extremelly useful Ctrl+Alt+I is calling something else... so it's not working there afaict

    There is an addon for krunner (krunner-appmenu) that i thought would enable it to do the same thing as the "command bar" - which would be awesome...
    (Update: i have figured it out: you have to enable global menu by placing it on the window titlebar - or somewhere else... and this way krunner is able to get the menu itens and perform the search... still it would be great if we could make this search from krunner without having to enable the globalmenu thing...)

    ngraham is there any plans to have this running on krunner as well - i mean being able to search some appplication feature/action from krunner?
    Last edited by Mavman; 24 May 2021, 11:37 AM.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by 144Hz View Post
    KDE should end the WM dictatorship (SSD only ) and start listening to the users, devs and designers who request better decorations (SSD+CSD)
    GNOME would need to adopt SSD+CSD as well as them, KDE, and more would have to agree upon something like my idea below.

    My idea for a solution is Apps can do what they want but the WM should be able to push down the Header Bar to allow for extra SSD controls if the user needs them via a key combo or dynamically like a taskbar and mouse (I have reservations about that due to the potential for misclicking things). Apps should be designed to expect to lose 50 pixels from being pushed down and the WM should be expected to be able to add in view movement bars. It seems really odd for every single app to have to implement things like "move to desktop X", "sticky here", "roll up", "stay above other windows", "stay behind other windows", and more. Those all sound like functions of a Window Manager and Environment...maybe even something that should be a low-level Wayland standard. Like, the lowest level function of a Wayland Window is simply an empty box where F1 slides in some Window Manager controls if that makes sense. I think that would solve a lot of problems a lot of different camps have.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by ngraham View Post

    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.
    Thanks for the reply.

    Not gonna lie, I always get chuckle when I read "Arch, Antergos, Manjaro" on the dependencies page. One of these three does not belong; doesn't exist. That could probably be changed to something like "Arch and Arch-based distributions". I used to like and recommend Manjaro but my experience with them over the long term is snapshots of Arch sound better in theory than they work in practice.

    I was hesitant to ask because we've had a similar discussion in the past and I didn't want you to think I was the boy who cried wolf. Due to the venue and level of appropriateness I didn't want to ask more than a distribution suggestion. I didn't think I was the only one in a venue full of Linux enthusiasts and developers with a curiosity about what distributions KDE developers use and would recommend.

    Linux Distributions for $1000

    What are the three distributions I'd have the hardest time picking between?

    Fedora, Tumbleweed, and Arch. I'm most comfortable with Arch but all three have good merit and reason for why I like them. What a toughie.

    Leave a comment:


  • Vistaus
    replied
    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.

    Leave a comment:


  • ngraham
    replied
    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.

    Leave a comment:


  • curfew
    replied
    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.

    Leave a comment:


  • curfew
    replied
    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.

    Leave a comment:


  • curfew
    replied
    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.

    Leave a comment:

Working...
X