- User Since
- Sep 1 2015, 10:58 AM (247 w, 5 d)
Tue, May 26
Mon, May 25
Wait @davidedmundson to accept it.
Wed, May 20
So change should be fine, (https://phabricator.kde.org/source/plasma-workspace/browse/master/appmenu) since KDED loads only modules they don't know where and when qApp is instantiated.
Tue, May 19
Mon, May 18
Is that KWin that set titlebar menus?
Sun, May 17
But I'm not quite ready for 5.70 yet, that would probably mean recompiling most of KDE
Commented code should be removed.
Sat, May 16
I miss something here, the idea behind the patch is to have pixel metrics in thickness, geometry etc. @boemann i got your opinion as to have configurable pixel units, is that right?
Fri, May 15
Thu, May 14
Rebase on master
Wed, May 13
Thank you, i should wait ship it, but just got Dag comment as it is.
Should it /var/lib/flatpak (or just /flatpak/) be included as well?
Seems fine, i'll push pageapp/flake changes as part of this review in 3.2 branch and master, refactoring main window in separate commit master only.
Tue, May 12
@danders i saw you patch on my email. d->viewportWidget->canvas()->removeEventFilter(this); fixes the issue but i still prefer all of refactoring code. Please test on all components does not have regressions.
Mon, May 11
We should call removeEventFilter or found exactly why signal is emitted in destructor.
d->rootPart->createView(doc, this); Creates the view which parent is main window.
Sat, May 9
Add more context
Fri, May 8
Thu, May 7
Wed, May 6
I don't see why qApp is not deleted here
Sat, May 2
KNewstuff is framework, it has only master.
Apr 29 2020
Is this still WIP, it looks good, can we proceed?
Apr 28 2020
The idea is to remove some of the configuration possibility: for example only allowing the KoModeBoxDocker to be a left or right sidebar. (putting at the top and bottom was completely broken anyway so I don't think many people did it).
I don't know why everyone wants tools to be above edit window. That's pretty old style when resolution ratio was 4:3 that's why they was arranged one above another. But i agree that it should be flexible to be horizontal or vertical as needed.
Apr 27 2020
What kind of GHNS dialog you spot about? It's a service menu, right click on supported file format (deb, rpm, zst)
+1, well done. Wait ship it from maintainer.
You can rename summary to inform that Debian, RPM and Pacman packages are supported.
Apr 22 2020
Apr 20 2020
Apr 18 2020
+1, looks great.
Apr 17 2020
Apr 14 2020
Create patch like this git diff -U999 > 1.patch it will add more context to be shown to reviewers.
Apr 9 2020
Apr 8 2020
If you want to kill the job how this loop will be break?
Apr 5 2020
@elvisangelaccio this peace of code is purely wrong at least m_storages is not updated to new device and not only. This code should never exists or try to hide some other bug.
Apr 4 2020
OK, let's keep things as they are. Because the best i can make without dedicated function is new KIO::ApplicationLauncherJob(service, KIO::ApplicationLauncher::WITH_AUTO_ERROR_HANDLED_DELEGATE)
Ok that's look good to me. We can move that code in constructor just before loop for storages, then use m_mtpdevice instead of raw device, but it looks like removed code is just a noise and it shouldn't present at all.
And what about the idea to pass delegate to job constructor? At least it's better than current one. I'm pretty pedantic about duplicate code in plus it makes porting harder.
Apr 3 2020
@feverfew are you gonna try what i'm writing about or i should do it? Just use cached device, do not reopen since it'll return nullptr.
I see we don't speak in same language :)
returns nullptr that's normal since device is inaccessible, i mean it does not need to call LIBMTP_Release_Device using m_mtpdevice is safe it's not nullptr, it's just a disconnected device and libmtp knows that.
You're right about bug report, but it can fail in any other place, just in particular version it happen in updateStorageInfo Can we cache getDevice in m_device (in constructor) then use it everywhere. I think libmtp has guard against disconnected device and will not crash.
Apr 2 2020
Apr 1 2020
Mar 31 2020
Mar 29 2020
Mar 28 2020
Why not? Furthermore they can be easy fixable.
Mar 26 2020
Mar 19 2020
Because KWayland is a KF library,
we are not able to change existing API in ways that may break API or
ABI compatibility. So, if some particular wrapper has been implemented
incorrectly, we can't do that much about it except maybe leaving
comments that look like "// TODO KF6".
Mar 17 2020
Can we just set/clear OverlayIconName depends of icon presence then overlays: model.OverlayIconName ?