Announcement

Collapse
No announcement yet.

KDE Plasma 6.0 Is Enabling Wayland By Default, Initial Support For HDR-Capable Games

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

  • ngraham
    replied
    Originally posted by dpeterc View Post
    I can not claim that developers recommend(ed) this step.
    But as a user (and many times administrator of other people's computer setups), I don't care so much about debugging KDE apps. I have to solve the user's need to access their files and do regular work.
    Typically situation, which happened many times in the past, was some bug in KDE applications and settings, where user could not log in. Kde was stuck in the initialization stage. And the simple solution was to wipe all settings KDE and the system was working again.
    Can you give some more details about exactly which files and settings caused these issues? Do you have any links to bugzilla tickets about any of these issues? Also, howfar in the past are we talking about here? 1 year? 2 years? 5 years? 10 years? 20 years?

    Originally posted by dpeterc View Post
    On a side note, one problem, probably deeply rooted in KDE ways of doing stuff, is the inability to login with a full disk. In my opinion, all programs should work even without free space (and/or writing temporary files). If the disk is full, some functionality is obviously impossible, and programs can issue a warning about that, same way as you can't write a write protected file. A working desktop system with a full disk should allow deleting of files and restarting the system.
    Currently, with disk full problem is extremely difficult to diagnose and correct by remote administration tools ... all we have is a customer complaining that they can't login, and no way to access the system by desktop remote connectivity tools (like TeamViewer).
    I'm not aware of this issue. Do you have a link to a bugzilla ticket about it?

    Leave a comment:


  • bosslog
    replied
    - Preliminary support for playing HDR-capable games on HDR-capable displays with the Plasma Wayland session.​
    What about 10-bit color to reduce banding on 10-bit capable monitors?

    - Ark is now much faster at compressing files using XZ and Zstd by enabling multi-threading.
    Finally! I've resorted to creating .tar's with Ark and then manually doing zstd -T0 archive.tar, but it's much easier to just have it work directly from the context menu.

    - The Meta + Escape shortcut will now launch the KDE System Monitor.
    Interesting that they went with Meta + Escape instead of Control+Alt+Escape like Windows.

    Leave a comment:


  • varikonniemi
    replied
    It looks so good and promising release, might finally make wayland the standard.

    Most important aspect is of course it working right. But god damn would it not be nice to have it also look technically nice, like having a sane config file layout!
    Last edited by varikonniemi; 11 November 2023, 04:15 PM.

    Leave a comment:


  • dpeterc
    replied
    Originally posted by ngraham View Post
    We never recommend resetting all KDE settings as a debugging step; that doesn't make sense. What we do recommend is resetting targeted settings that we suspect might be causing a problem (and in this case we'll tell you which file to move aside), or we recommend trying to reproduce the problem in a new user account which is the functional equivalent of resetting everything--KDE and non-KDE settings alike (because this can also catch cases where you've messed up your PATH variable or something else about your login environment). But resetting only KDE settings is generally not a useful debugging step.
    I can not claim that developers recommend(ed) this step.
    But as a user (and many times administrator of other people's computer setups), I don't care so much about debugging KDE apps. I have to solve the user's need to access their files and do regular work.
    Typically situation, which happened many times in the past, was some bug in KDE applications and settings, where user could not log in. Kde was stuck in the initialization stage. And the simple solution was to wipe all settings KDE and the system was working again.

    On a side note, one problem, probably deeply rooted in KDE ways of doing stuff, is the inability to login with a full disk. In my opinion, all programs should work even without free space (and/or writing temporary files). If the disk is full, some functionality is obviously impossible, and programs can issue a warning about that, same way as you can't write a write protected file. A working desktop system with a full disk should allow deleting of files and restarting the system.
    Currently, with disk full problem is extremely difficult to diagnose and correct by remote administration tools ... all we have is a customer complaining that they can't login, and no way to access the system by desktop remote connectivity tools (like TeamViewer).

    Leave a comment:


  • avis
    replied
    Given a decent number of comments and at least three duplicates people indeed are interested, but I won't push this any further.

    Let's just say this but report is about making kde neat and tidy.

    Leave a comment:


  • ngraham
    replied
    Originally posted by avis View Post
    ngraham
    The bug report contains at the very least two other strong arguments why the status quo is just bad.

    One of them is that KDE developers themselves often recommend to reset settings and the way KDE config files are organized right now makes it almost impossible aside from nuking other unrelated applications settings.
    We never recommend resetting all KDE settings as a debugging step; that doesn't make sense. What we do recommend is resetting targeted settings that we suspect might be causing a problem (and in this case we'll tell you which file to move aside), or we recommend trying to reproduce the problem in a new user account which is the functional equivalent of resetting everything--KDE and non-KDE settings alike (because this can also catch cases where you've messed up your PATH variable or something else about your login environment). But resetting only KDE settings is generally not a useful debugging step.


    Originally posted by avis View Post
    I won't create an offer in the kde sponsored work section because one person has already done the work which was rejected and only core KDE developers have the idea how it needs to be done properly but they are just not concerned. It would be sad if someone wrote yet another implementation only to get it rejected.

    I just wonder if it's a low hanging fruit (which in my limited knowledge of English means it can be done easily) why it hasn't already been done.
    Because as I said, the people who can do it don't care enough to do so, and would prefer to work on other things instead. This includes me. I could do it, but I prefer to use my time working on things I find to be more impactful for more people.

    Leave a comment:


  • avis
    replied
    ngraham

    The bug report contains at the very least two other strong arguments why the status quo is just bad.

    One of them is that KDE developers themselves often recommend to reset settings and the way KDE config files are organized right now makes it almost impossible aside from nuking other unrelated applications settings.

    timofonic

    I won't create an offer in the kde sponsored work section because one person has already done the work which was rejected and only core KDE developers have the idea how it needs to be done properly but they are just not concerned. It would be sad if someone wrote yet another implementation only to get it rejected.

    I just wonder if it's a low hanging fruit (which in my limited knowledge of English means it can be done easily) why it hasn't already been done.
    Last edited by avis; 11 November 2023, 12:49 PM.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by skeevy420 View Post

    My current monitor is a 55" 4K TV. While nice for media consumption and video, 4K is overkill for my GPU playing games and there isn't a scaling solution that I find acceptable as well as it is a real pain in the ass to do text editing on a TV across the room. FSR ghosting is really bad on a 55" 4K screen since the pixels are spread out further.

    I swear to god that they, AMD FSR devs, don't test stuff out on moronic consumer setups.
    I myself have a 27" 4k monitor, I have about a 1.20 scale factor, so around 1800p, and for me thats my sweet spot with how far away I sit from my monitor, it gives me plenty of realestate for working on so I can have multiple windows open at once.​​

    Leave a comment:


  • timofonic
    replied
    Originally posted by ngraham View Post
    Apps just need to opt into the more categorized config file style, and there are no technical blockers to doing so; see https://rabbitictranslator.com/kconfig.

    I think the reason why it hasn't gotten done yet is because most KDE developers don't care about it and don't see the status quo as a major issue. I know that describes me. Would it be nicer if config files were better categorized? Sure. But how often do normal people manually view or edit config files in hidden folders? Never. This is only a point of irritation for technically advanced OCD people who are obsessed with categorization. And that's fine! Those people have a valid opinion and a right to exist. But they're a small group of people and the thing they're upset about not important to anyone else. That might sound a bit harsh, but it's the reality of the situation. So I think if this is going to get done, it will be when the people who care about it start submitting patches to make their favorite KDE apps use the better-categorized approach. Again, see https://rabbitictranslator.com/kconfig for a description of what code changes are necessary. It's pretty low-hanging fruit.

    And no, this can't be done universally because the place where a universal change would need to be done (KConfig) isn't limited to being used by KDE software, so we don't want to end up putting non-KDE apps' config files in a KDE folder.
    You have a valid point. I'm one of those categorization obsessed people. And I mess with "hidden files" all time, it's even one of my hobbies and part of my daily job.

    I think there may be more OCD nerds out there, seriously. Many of them may be programmers, others not.

    If it's a low hanging fruit, maybe it may be requested as KDE Sponsored Work.

    Thanks for saying we have a valid opinion and a right to exist! I didn't read that before from other developers, I'm used so much of dealing with extremely authoritative developers.

    avis
    Are you interested to use your OCD skills to submit the request?
    Last edited by timofonic; 11 November 2023, 12:29 PM.

    Leave a comment:


  • ngraham
    replied
    Apps just need to opt into the more categorized config file style, and there are no technical blockers to doing so; see https://rabbitictranslator.com/kconfig.

    I think the reason why it hasn't gotten done yet is because most KDE developers don't care about it and don't see the status quo as a major issue. I know that describes me. Would it be nicer if config files were better categorized? Sure. But how often do normal people manually view or edit config files in hidden folders? Never. This is only a point of irritation for technically advanced OCD people who are obsessed with categorization. And that's fine! Those people have a valid opinion and a right to exist. But they're a small group of people and the thing they're upset about is not important to anyone else. That might sound a bit harsh, but it's the reality of the situation. So I think if this is going to get done, it will be when the people who care about it start submitting patches to make their favorite KDE apps use the better-categorized approach. Again, see https://rabbitictranslator.com/kconfig for a description of what code changes are necessary. It's pretty low-hanging fruit.

    And no, this can't be done universally because the place where a universal change would need to be done (KConfig) isn't limited to being used by KDE software, so we don't want to end up putting non-KDE apps' config files in a KDE folder.
    Last edited by ngraham; 11 November 2023, 12:25 PM.

    Leave a comment:

Working...
X