All uncertain features go in here, if they're still there after a year, they'll get deleted.
Fixed in Krita 4.x
Fri, Oct 11
Is this resolved?
Handled by @hellozee
Mon, Oct 7
Btw, the Shortcuts page does some very weird things if you resize the settings dialog manually.
It might be a good idea to look at the classes we use for the settings dialogue. The KPageDialog/KPageView/KPageWidget hierarchy is pretty old-fashioned looking and no longer fits with what people who are used to e.g. Windows's "new" Settings app are used to, so we have a clash of expectations. People don't expect an apply/okay/cancel set of buttons anymore, it seems.
Sun, Oct 6
This conversation about the settings dialog has came up multiple times in the last 4-5 years I have been helping. We usually do some work to make it smaller, then of course more options get added that make it larger again. I think all we can do is find out what area is taking the most space...and figure out ways to make it take up less space.
I wonder if we can do some kind of integration test that fails whenever the dialog is above 700px...
- It could be just a rule: "if you add anything to settings, make sure it doesn't make it bigger than [maximum allowed size]".
- It could make other things inaccessible. But it should be enough for the user to be able to disable HiDPI mode.
- would work, but... I don't want to see the scroll view there. If it's gonna be an automatic one, that hides itself if it's not needed, then sure, but... it's just ugly and inconvenient. I dislike the scroll view with categories, too.
- Like 2., should be enough for disabling HiDPI mode.
- Like 2. and 4., should be enough to disable HiDPI mode.
Thu, Sep 26
Tue, Sep 24
Closing this ticket. We updated the UI a little while ago with some of the hold ideas listed here. Any other feedback can go in a new ticket.
HiDPI is there -- arguments += "&HiDPI=" + QString(QCoreApplication::testAttribute(Qt::AA_EnableHighDpiScaling) ? "true" : "false");
InstantPreviewEnabled becomes InstantPreviewEnable, because the question code can't get that long.
Mon, Sep 23
Here's some things I think we should encode in the URL:
Sun, Sep 22
I’m trying out a prototype in which I have decoupled the development build alert and new version notifications:
- When appimage updater is in use, there are also updates for dev builds. The area next to Start header is too crowded then.
- It makes more sense to me if the updater notification is under the “Check for updates” checkbox, not on the other side of the window.
Thu, Sep 19
Wed, Sep 18
Tue, Sep 17
Sun, Sep 15
Sat, Sep 14
What does the link do after it is done updating. The "To complete the update, run the new version". Does that restart Krita?
Sep 13 2019
maybe instead of 'update now', it could just say "update to newer version".
Current progress (still on localhost; the size of the appimage is not final, it's just my debug build). The core of the check and update process is done. I am not sure what to do with the UI part and reporting errors to users. I have added the update button and placeholder messages to the original area in the Start section, but it feels crowded and overall weird to me. Errors are logged to the usage log but not propagated to the user interface right now (apart from 'Error occurred' message). @scottpetrovic, may I ask you for a bit of your time to look at it with me?