- User Since
- Apr 15 2017, 7:18 PM (113 w, 1 d)
+1, makes sense!
Wow, thanks very much! To answer some questions:
Ah OK, I hadn't realized it got moved there yet. I guess this revision can be abandoned then, and we should lobby distros to ship with the new repo/package.
Thanks very much for the nice patch! May it be the first of many. :) Let me know if you need a hand with anything.
Plasma 5.16 has been released and master is wide open for new features. Can we get this landed in some capacity soon? It would be great to have more testing time.
So you think we should prioritize better prioritization? :)
You need to "abandon" it yourself using the Add Action... menu.
Just tried out that patch and it fixes both bugs! Let's get it in. :)
Looks like this also fixes 408244! Please address @elvisangelaccio's comment, then I think this can land.
Too micro, sorry. :)
I think this can be considered a subtask or duplicate of T11067.
IMO this should be closed as it's basically a bug report, not really a long-term goal.
I'm afraid I don't actually understand what's being proposed here. :)
LGTM! Thanks very much for this.
I personally think the biggest problem with our docs is not necessarily the content, but the organization. API docs in particular are very hard to find. And if I Google some class name in desperation, I get the old KDE4 era docs, not the KF5 stuff. https://api.kde.org doesn't seem to be linked to in many places. And then of course there's all the duplication.
One problem I see here is that "important long term problems" means something different to everyone who reads it. I think you need to be more specific or else this will become a "fix all the things" task that's impossible to achieve (if we had the resources to fix everything, we wouldn't need to set goals for prioritizing where our limited resources need to be spent).
Indeed. GUI tools that are thin wrappers around CLI programs generally fail because they have no ideal user: people who are comfortable with the CLI prefer the actual CLI, and people who don't like it want a GUI tool that's specifically designed to be a GUI tool. There are very very few people who want to interact with a CLI tool using a thin GUI wrapper.
I like the rounder corners! :)
Fri, Jun 14
+1 just for the amount of work you put into the proposal. It's clear you've been thinking about this for quite some time, and the problems are laid out very clearly. I agree with almost everything you say. It's these kinds of little inconsistencies that hurt KDE has a brand and makes the whole KDE ecosystem feel fragmented and unreliable, like nobody's coordinating everything. ...probably because it's true! Just a heads-up though: by far the biggest part of this goal is that coordination. If it's chosen, you're basically signing up to do it. :)
@rappelman can you please provide your email address so we can land this patch with correct authorship information? Thanks!
Also, take your time, no rush. :)
Make the MetaDataDelegate labels bold again
I can add back the bold:
I was also not sure about removing information. An idea I had was to make the actual toolbar itself very minimal and only show the category name + toolbar buttons. Then all the fancy information could be below that, visible in the view itself, separated in a pretty way like how I did with the context view.
Patch to fix: D21811
TBH I really don't like this message anyway. It's so in-your-face. But while it exists, I guess we should make it look prettier. :)
Yeah, this stuff is all second nature to us developers but to users--even potentially experienced users--it's not clear.
@matthieugras Ping! :)
Sorry this took so long @matthieugras! Since you've gotten several patches accepted now, please feel free to apply: https://techbase.kde.org/Contribute/Get_a_Contributor_Account
Interactivity is great, a big improvement! Code looks sane to me too but I'd like a review from a Okular person before we land this.
Is this still relevant?
+1, makes sense!
I'm a bit torn. For all the documentation I've updated that that's on a wiki, I seriously doubt I would have made the change if I'd needed to submit a patch, deal with bikeshedding, request commit access, etc. The barrier to entry for a wiki is just so low that it's a real advantage IMO.
I would recommend merging this into T11069, which is broader and more ambitious. :)
Thu, Jun 13
It was just a thought; the thing in System Settings could itself have a chooser for the instances in different activities and instead. I think it's worth keeping in mind that the common case is one screen and one activity. For the majority of our users, the configuration UI would be very simple. It would need to accommodate advanced use cases, but the simple one-screen-one-activity use case would be by far the most common one.
Code change looks sane, and I also can detect no regressions!
Nice huge diff! You see why I had trouble with it, maybe. :) I am very impressed that you pulled this off so quickly though!
So um, any chance we can move forward with this in some capacity?
This new Applications tab is basically a clone of SimpleMenu, XFCE's Whisker menu, or Excalibur Menu: https://store.kde.org/p/1172867/
Totally awesome :)
@mgerstner How is this looking now? Yea/nay?