- User Since
- Apr 15 2015, 5:07 PM (149 w, 4 d)
Thu, Feb 22
Tue, Feb 20
@ivan So you wrote a method that can return null, but the call sites aren't actually prepared to handle that gracefully? :) But I was waiting for your review for that context.
It does use it btw, just not for subdialogs.
No, you weren't: "What's the point of the desktop if it is not possible to place folder, pictures, music, etc on it?"
This isn't about disabling support for icons (we just turned that back on in 5.10 ...), it's about not creating the Home and Trash icons by default on first login.
This is just following up on a public promise we already made. When we turned Folder View into the default desktop containment, we told everyone (and got a lot of positive feedback from the users for it) that this means the desktop surface now supports icons by default again, but we don't actually place any by default so it's not having any impact on the people who prefer an empty desktop by default. Then it turns out we actually forgot to change the code.
I'll look into it, this week probably
Fri, Feb 16
Thu, Feb 15
Wed, Feb 14
I still feel pretty strongly that any correct version of this patch wouldn't actually add any code to Yakuake.
Tue, Feb 13
(Side note: I like the idea of a KRun job - something like that could even be added without needing a KIO 6.)
- Fall back to qWarning if !qGuiApp
- Use QTimer::singleShot to work on older Qt
There's a problem with my patch :(. QMetaObject::invokeMethod(context, functor) is new in Qt 5.10. I don't think we can depend on that yet, right?
It's totally conceivable for e.g. a KPart or a Plasma plugin to open a QWidget-based window where the KMessageBox is appropriate, and if there's only a global interface instance and Plasma overrides it to hide all message boxes it's going to break KIO users in plugins. So I don't think going to a single global is good enough, it would have to be able to set more narrowly. This also bubbles up actually - the KRun calls we're talking about are in libtaskmanager which is technically meant to be UI-agnostic, so it'd have to also expose some way to set the interface instance. I agree all of this is in theory good (we need to make KIO more toolkit-agnostic - I have another giant patch sitting around that's almost-unfinishable that adds QWindow support to some APIs that currently only accept QWidgets I don't even have), but I think it's KIO 6 material and not the quick fix I'm looking for.
There's a Job::setUiDelegateExtension though in addition to KIO::setDefaultJobUiDelegateExtension. A global would wreak havoc with stuff like plugins, no?
Thanks for the solution for sure, but - it requires writing a million lines of boilerplate, extensively refactoring KRun and adding reams of new overloads to its API (there would need to be some way to pass an instance of that interface to all these - not internal - statics). It's more than I have time/energy for currently and I'm not really sure it's viable without a KIO6. I have another idea, though, let me see if it's viable ...
Mon, Feb 12
/o\ I don't like life anymore
@dfaure I don't see how the virtual thing is going to work - there's numerous static affected codepaths so there's no 'this' to pass down to call the non-static error handler on.
Full Tab/Backtab nav also when searching.
Yeah, I had a feeling there were other design considerations here, but they're not documented/commented in the code so the only way to find out was to show you a patch :)
Sun, Feb 11
Sanity check question: Did you make sure this doesn't introduce an extra render when things start up? (Initial vs. change.)
This should go into master only for now.
This should go into 5.12 and then be merged up.
@ivan Could you suggest a good testcase? I'm a bit wary of pushing this into the LTS branch with a low amount of confidence.
Fri, Feb 9
Remove unrelated changes.
Argh, sorry for the noisy diff, I didn't do commit -a but arc did I guess ... I'll clean this up, one sec.
Thanks for your analysis! I actually did try roughly the same thing, but I thought keeping the behavior of having larger preview thumbs is nicer overall.
Thu, Feb 8
Ivan, could you weigh in on the KActivities spaces angle?
Sometimes I wish we'd implement lazy loading in the backends instead (e.g. why is heavy when it's never been visible). The more we optimize our QML the more we go procedural/non-declarative and hard to read sadly.
Wed, Feb 7
As mentioned, I'm OK with abandoning it. I think the change is hygienic, but it's also a micro-optimization.
Tue, Feb 6
Empty desktop doesn't close it for me without this patch.
Well, the maintainer spoke out against it, so not much I can do.
I can't help but feel increasingly bad about the whole applications: URLs thing. If we have to patch 5000 places something is not right. We need to come up with a better way some time soon. What are we doing wrong? Maybe we should just pass KServices around? Hmm.
Mon, Feb 5
Fri, Feb 2
It's definitely nicer, but could we go for the full thing and make it crisper too?
Thu, Feb 1
Sat, Jan 27
This looks up my PC several times a week. I lose work regularly because of it, and often can't finish compiling plasma-desktop successfully. I'm very +1 for killing it.
Jan 25 2018
@anemeth The patch doesn't apply cleanly to current master. Would you mind rebasing it please? I don't want to introduce errors at this stage by editing code I didn't review.
I'll push this for you (I'm interpreting Martin's resignation as withdrawing objections, knock on wood).
Identical patches to this one have been written a few times and are strewn about Phabricator and ReviewBoard (defunct), but all suffer similar problems:
Jan 24 2018