- User Since
- Sep 1 2015, 10:58 AM (263 w, 4 d)
Fri, Aug 28
Jul 1 2020
Ping, it should be committed?
Jun 27 2020
I test, current situation, i don't think the parch is needed as is. 2 monitors FullHD and 4K (HDMI) now KScreen does not allow different scale factor to distinct monitor but you can change the kdeglobals
[KScreen] ScaleFactor=1 ScreenScaleFactors=eDP1=1;HDMI1=2;VIRTUAL1=1; # NOTE 2 on HDMI
That seems to work, but not well enough. When you move window from low res monitor to high res one window is scaled automatically, but it seems glitchy. Window content is looking a bit broken (font is scaled and readable well)
Jun 23 2020
Jun 21 2020
Ping, do not forget.
Jun 6 2020
Jun 1 2020
@ngraham i don't think it's needed this for existing reviews, it's double work for nothing.
It has 2 weeks testing before 5.71 release just push it, it can be reverted if broke something.
May 26 2020
May 25 2020
Wait @davidedmundson to accept it.
May 20 2020
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.
May 19 2020
May 18 2020
Is that KWin that set titlebar menus?
May 17 2020
But I'm not quite ready for 5.70 yet, that would probably mean recompiling most of KDE
Commented code should be removed.
May 16 2020
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?
May 15 2020
May 14 2020
Rebase on master
May 13 2020
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.
May 12 2020
@danders i saw your 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.
May 11 2020
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.
May 9 2020
Add more context
May 8 2020
May 7 2020
May 6 2020
I don't see why qApp is not deleted here
Probably because it can be allocated on stack.
May 2 2020
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.