Announcement

Collapse
No announcement yet.

KDE Plasma 6.0 Beta 1 Released With Frameworks & Gear Updated

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

  • ehansin
    replied
    For posterity's sake, since I brought up the ~/.config issue, I had just never really gotten much feedback on this before. I posted about this same issue on here a couple/few years ago, and heard little other than one response that it could get changed. So I took a look at the released KDE 6 beta just to see what the deal was. Same thing, so posted about it, just to see if any feedback.

    I will add, this was an issue that I noticed right away in a past KDE installation, and have never much used KDE (though have nothing against it at all, just never stuck with it.) I tend to notice small details, probably more than the average person for sure. This sort of thing just sticks out to me. In the end, not a big deal. But was something I had wanted to follow up on given the one response from before when I previously mentioned. Do I think there is value in what I mentioned? Sure. But is it something I should lose sleep over? Surely not. In the end, something that really should be decided by people doing the work, which is not me. I was just curious about the whole thing.

    Leave a comment:


  • bug77
    replied
    Originally posted by fallingcats View Post


    Is it really that hard to understand that while organizing .config is something nice to have, it's not more important than the other goals for 6.0 like fixing up wayland? You also really seem to overestimate the manpower of the project as a whole. If it's that important to you (as has been said countless times) patches are welcome!​


    Originally posted by smitty3268 View Post

    It means prioritization is important. And I'm very skeptical of the honesty of anyone who claims that this is the only thing stopping them from using KDE, or the most important thing to fix.
    Well, I never said it was a deal breaker. I've been using KDE for over 10 years, tyvm, so no deal breaker, indeed.
    And while this isn't a deal breaker or high priority, it is a low-hanging fruit, especially since presumably every app has undergone some scrutiny to make sure it works with Qt6. Leaving that mess behind, is a missed opportunity.

    Hearing that argument from a developer that "it works" is disheartening as well.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by skeevy420 View Post

    The fact that we're still discussing this is damn weird. To me, this is one of those issues that you bring up as an example of how KDE is doing it right. By that I just mean that we're at the point to where we have to look for something as asinine to complain about as the location of the config files.

    Although, one good thing about the config issue is how it highlights the rationality of people by acting as a great moron detector.

    I won't use KDE cause the config files aren't stored properly. Herp-a-derp-a-doo.

    Quackdoc I'm not. My HDR on Linux experience is very limited, especially outside of Gamescope.
    the flag is used to specifically signal that mpv should be passing colordata through to the host instead of converting it internally. its the same on windows btw

    Leave a comment:


  • skeevy420
    replied
    One last thing, just thought I'd share the Steam command I'm using to launch Baldur's Gate 3 in HDR

    Code:
    env --unset=SDL_VIDEODRIVER ENABLE_HDR_WSI=1 gamescope -H 1440 -W 3440 -r 144 -f --hdr-enabled --hdr-debug-force-output --steam -- env ENABLE_GAMESCOPE_WSI=1 DXVK_HDR=1 DISABLE_HDR_WSI=1 %command%
    Adjust the H, W, and r to your monitor's specs. I'm using DX11. Vulkan crashes on my system (yes, I've deleted the cache file).

    That'll likely work for any HDR game that doesn't pickup up KDE's HDR....remove "env --unset=SDL_VIDEODRIVER" for other games....that's a Baldur's Gate 3 workaround.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by smitty3268 View Post

    It means prioritization is important. And I'm very skeptical of the honesty of anyone who claims that this is the only thing stopping them from using KDE, or the most important thing to fix.
    The fact that we're still discussing this is damn weird. To me, this is one of those issues that you bring up as an example of how KDE is doing it right. By that I just mean that we're at the point to where we have to look for something as asinine to complain about as the location of the config files.

    Although, one good thing about the config issue is how it highlights the rationality of people by acting as a great moron detector.

    I won't use KDE cause the config files aren't stored properly. Herp-a-derp-a-doo.

    Quackdoc I'm not. My HDR on Linux experience is very limited, especially outside of Gamescope.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by skeevy420 View Post

    OK, so I did a little more testing with an HDR calibration file, 02. White 240-1000nits-MaxCLL-1000-MDL-1000.mp4, and found that I had to run it with "mpv --vo=gpu-next --target-colorspace-hint=yes" to output in HDR. The gamma line was the same either way. I seemed to have learned bad information in a random mpv git issue.

    Quackdoc Figured you'd want to know that.

    Yeah I am familiar with that one

    Leave a comment:


  • skeevy420
    replied
    Originally posted by fallingcats View Post

    Okay maybe that just means I'm dumb, but I didn't notice a difference compared to sdr on full brightness

    Edit: No I've just checked, The "Gamma:" line is exactly the same as yours even when I'm running in SDR (hdr disabled in kscreen-doctor and my monitor confirms it's not in HDR mode)
    OK, so I did a little more testing with an HDR calibration file, 02. White 240-1000nits-MaxCLL-1000-MDL-1000.mp4, and found that I had to run it with "mpv --vo=gpu-next --target-colorspace-hint=yes" to output in HDR. The gamma line was the same either way. I seemed to have learned bad information in a random mpv git issue.

    Quackdoc Figured you'd want to know that.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
    accessible configuration in simple shell scripting
    Back when mailing lists were still a thing I was quite active in supporting users and there used to be kreadconfig & kwriiteconfig for easy checking and setting values without the need to find or parse files.

    They even took into account hierarchical settings spread over directories (e.g. system wide settings combined with group and/or user settings(, variables in settings and restrictions defined through the KDE Kiosk framework.

    Unfortunately my shell history doesn't include any examples anymore

    Cheers,
    _

    Leave a comment:


  • fallingcats
    replied
    Originally posted by skeevy420 View Post

    That's all I did, aside from using brightess.300.

    Tap "i" when running mpv and check the gamma line to see if it works. Mine says "pq (HDR peak: 1000 nits)"

    EDIT: I'm running CachyOS with mpv from the repos and Plasma built from source. Ironic how we're backwards from each other in our software choices
    Okay maybe that just means I'm dumb, but I didn't notice a difference compared to sdr on full brightness

    Edit: No I've just checked, The "Gamma:" line is exactly the same as yours even when I'm running in SDR (hdr disabled in kscreen-doctor and my monitor confirms it's not in HDR mode)

    Leave a comment:


  • smitty3268
    replied
    Originally posted by bug77 View Post
    Sooo... let's not fix anything, ever?
    It means prioritization is important. And I'm very skeptical of the honesty of anyone who claims that this is the only thing stopping them from using KDE, or the most important thing to fix.

    Leave a comment:

Working...
X