KDE's Multi-Monitor Support Continues To Be Improved

[Vistaus]

The problem is the maintainer putting it on you to play "yes, it's still a problem" ping-pong until you give up and go away years later.

It's true that developers sometimes are a bit stubborn. I had that on KDE Bugs too recently: for one feature request, he didn't think it would be popular enough to implement it systemwide, so I had to request it on a per-app basis instead of systemwide. So he'd rather I flood the rest of the devs with 20 bug reports for the 20 apps that I use rather than just implement it systemwide…

[TemplarGR]

And then those extensions don't get updated anymore and we're back to square one…

Who cares? If they are extensions, they are not part of the main project. Those who need them will update them, if they do not see updates, then they are not that important it seems...

[Vistaus]

It is not sensible to keep bugs open for more than a decade. The project has changed A LOT since then. A LOT. From switching 2 (soon 3) times their Qt base, to their other frameworks, changing applications, window managers, display protocols, APIs, etc etc. If a bug wasn't closed at that point, it may have been fixed (but not tested) ages ago, or simply is not relevant anymore because of all the changes.

You said it yourself, you do not even use the bugged apps anymore yourself so you can't test if the bugs still apply... And you were the one who wrote the bug reports... Do you expect opensource developers with their limited resources and time, to go by the list and try to test constantly decade old bug reports to see if they still apply?

The procedure is to simply close -very- old bug reports, and if they persist, someone will open them again. That is the sensible thing to do, i don't see where the problem is.

I don't disagree with you, but it would be nicer from a user POV if the bot gave you a little heads-up. Something like “let us know if you still have this issue, otherwise this issue will be automatically closed in 15 days”.

[Berniyh]

I don't disagree with you, but it would be nicer from a user POV if the bot gave you a little heads-up. Something like “let us know if you still have this issue, otherwise this issue will be automatically closed in 15 days”.

Uhm, most bug trackers that I have seen using such bots actually do this.

Also, you can usually reopen the ticket if you think that it is still valid.

[Vistaus]

Uhm, most bug trackers that I have seen using such bots actually do this.

Also, you can usually reopen the ticket if you think that it is still valid.

I have not seen KDE Bugs do that, but yes, you can reopen it there if you want to.

[ssokolow]

It is not sensible to keep bugs open for more than a decade. The project has changed A LOT since then. A LOT. From switching 2 (soon 3) times their Qt base, to their other frameworks, changing applications, window managers, display protocols, APIs, etc etc. If a bug wasn't closed at that point, it may have been fixed (but not tested) ages ago, or simply is not relevant anymore because of all the changes.

You said it yourself, you do not even use the bugged apps anymore yourself so you can't test if the bugs still apply... And you were the one who wrote the bug reports... Do you expect opensource developers with their limited resources and time, to go by the list and try to test constantly decade old bug reports to see if they still apply?

The procedure is to simply close -very- old bug reports, and if they persist, someone will open them again. That is the sensible thing to do, i don't see where the problem is.

That's the essence of the CADT model. The underlying sense that there's no point in reporting bugs because the developers are so focused on implementing new features that they're just going to ignore your reports unless they're bugs that the developers would have noticed themselves anyway.

That's why I don't report bugs in KDE anymore. I reported a dozen or two maybe a decade ago and the only two bugs I was even subscribed to which got fixed were ones where the fixing apparently had no connection to the existence of a bug report. (I think one of them was a KDE 3.5.x → 4.0 regression that was realized to have been fixed some time in the 5.x series.) Complete waste of time.

I haven't quite given up on UPX yet, since it's so simple to post a "still a problem" message on GitHub every time their bot tries to close my "GitHub Pages-hosted site is missing useful information that was on the UPX website back when it was hosted on SourceForge" bug for inactivity.

Sure, I actually have ADHD and have projects where bugs have been left open for years while I try to get my executive dysfunction enough under control to give my personal projects the TLC they need... but I respect the bug reporters enough that I will never give reporters the impression that I'm ignoring their bug report. If a bug gets closed, they'll at least get a personal message saying that I tested it myself and couldn't reproduce, or that I implemented the feature in a rewrite and forgot to close their report... and the initial triage where I decide if something is WONTFIX/NOTABUG happens promptly, even if going beyond that can take years... and if it does take years, it'll be clear that it's because the project is languishing, not because I'm letting features that I think are neat jump the queue.

(With QuickTile, for example, the "nifty new feature" that I made progress on before COVID sent my personal project time management into a spiral, a configuration GUI so you don't need to hand-edit the config file, was part of one of the oldest roadmap entries on the entire project and also one of the things needed to unblock so many more... the GUI is needed to prevent a usability regression when going from an INI-style config file to a JSON config file and to close at least one ancient bug about it failing to make it clear why your keybinds aren't getting picked up. The JSON config file is needed to prevent a usability regression when un-hardcoding the last remaining things you have to edit QuickTile's source to change (things that need hierarchical data). Once that's done, I'll have paid down the technical debt that's blocking the rework of how window positions are defined, allowing me to close a forest of other bugs that have built up over the years related to things like rounding errors in window dimensions opening up one-pixel gaps.)

[ssokolow]

I have not seen KDE Bugs do that, but yes, you can reopen it there if you want to.

To be fair to them, their bot gave me a 30 day grace period. I just wasn't going to waste my Christmas holidays on bug reports the developers had clearly never even looked at and were never going to fix.

[Nth_man]

I have not seen KDE Bugs do that, but yes, you can reopen it there if you want to.

If you want, you can use Google to search that: needsinfo site:bugs.kde.org

[tornado99]

My main problem with KDE is somebody says "can you add a menu or GUI option for this"....KDE adds option...and now every single menu and preference pane is completely overstuffed with niche settings that would be better left as terminal options, or some kind of "advanced settings" pane.

[bug77]

There is nothing wrong with trimming the fat. It is part of being FOCUSED. Having a boatload of semi-maintained features that most don't care about does not make a proper desktop. That is why plugins and extensions and shit exist in various projects, let the devs FOCUS on their vision and let others extend it as they see fit.

There is much wrong with trimming the fat when you don't have a clear cut definition of what constitutes "fat".

Also, because of that, your "focus" is my "don't care".