[krita] [Bug 486529] New: Data loss on layer style Hard Mix Softer blendmode
https://bugs.kde.org/show_bug.cgi?id=486529 Bug ID: 486529 Summary: Data loss on layer style Hard Mix Softer blendmode Classification: Applications Product: krita Version: 5.2.2 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: layer styles Assignee: krita-bugs-n...@kde.org Reporter: knowz...@pokemail.net Target Milestone: --- SUMMARY When you copy a layer style or save a document with the Hard Mix Softer blend mode, the blend mode is lost and goes to Normal STEPS TO REPRODUCE 1. Create any layer style with the Hard Mix Softer (Photoshop) blend mode 2. Copy the layer style and paste it to another 3. Check the layer style alternative 1. Create any layer style with the Hard Mix Softer (Photoshop) blend mode 2. Save the document and then close it 3. reopen the document OBSERVED RESULT Blend mode is reset to Normal ASL shows: EXPECTED RESULT SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5 ADDITIONAL INFORMATION The normal layer blend mode for Hard Mix Softer seems to be fine so this is only for layer styles I set severity to major based on previous data loss being market as major -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 451473] The "Animated PNG Image" export has file extension .png instead of .apng
https://bugs.kde.org/show_bug.cgi?id=451473 Know Zero changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Know Zero --- Git commit 74264d2a7f70b179dbc52dc837a1249a0bd288f4 Mon, 21 Mar 2022 01:14:30 -0400 [PATCH] Bugfix: Make APNG format for export consistent This patch makes apng the default format in the filename textbox for export instead of png, making it consistent with the file dialog. Fixes BUG #451473 --- libs/ui/animation/KisDlgAnimationRenderer.cpp | 4 ++-- libs/ui/animation/VideoExportOptionsDialog.cpp | 4 ++-- libs/ui/animation/VideoExportOptionsDialog.h | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) https://invent.kde.org/graphics/krita/-/commit/74264d2a7f70b179dbc52dc837a1249a0bd288f4 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 451473] The "Animated PNG Image" export has file extension .png instead of .apng
https://bugs.kde.org/show_bug.cgi?id=451473 Know Zero changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #5 from Know Zero --- @Bourumir Wyngs - The problem here isn't the mimetype, the problem here is the format. When you save via dialog, the default format is .apng, and the default in the entry is .png. It should be consistent. While technically, both apng and png formats are correct formats. Since apng has not officially be accepted by the PNG WorkGroup it probably make sense to keep the format apng. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 451473] The "Animated PNG Image" export has file extension .png instead of .apng
https://bugs.kde.org/show_bug.cgi?id=451473 Know Zero changed: What|Removed |Added CC||knowz...@pokemail.net --- Comment #2 from Know Zero --- Since I worked on this code, can I assign this bug to myself? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 451385] Copy and pasting a layer with an existing layerstyle fails to save changes
https://bugs.kde.org/show_bug.cgi?id=451385 --- Comment #1 from Know Zero --- Created attachment 147433 --> https://bugs.kde.org/attachment.cgi?id=147433=edit A sample KRA with layer copied and pasted sharing a resource -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 451385] New: Copy and pasting a layer with an existing layerstyle fails to save changes
https://bugs.kde.org/show_bug.cgi?id=451385 Bug ID: 451385 Summary: Copy and pasting a layer with an existing layerstyle fails to save changes Product: krita Version: nightly build (please specify the git hash!) Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: layer styles Assignee: krita-bugs-n...@kde.org Reporter: knowz...@pokemail.net Target Milestone: --- SUMMARY There seems to be a bug where a the style resource is not duplicated when a layer is copy and pasted into the same document. In both 5.0.2 and 5.1 nightly. STEPS TO REPRODUCE 1. Create a layer, add a stroke and a color overlay to the layer 2. copy the layer and paste it into the same document 3. now modify the original one with a different overlay color (you may wish to hide the other layer) 4. save and close 5. open it up OBSERVED RESULT changes to the overlay were not changed. It seems to be keeping a single resource for both under styles even after you change the original. EXPECTED RESULT Another resource should probably be created and changes saved. SOFTWARE/OS VERSIONS OpenSuse 15.3 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447650] Eraser part of the pen for Wacom Cintiq 16 does not work, had to go back to Krita 4.4.5
https://bugs.kde.org/show_bug.cgi?id=447650 Know Zero changed: What|Removed |Added CC||knowz...@pokemail.net --- Comment #2 from Know Zero --- I can confirm this bug on my old Wacom Graphics with both KDE OpenSuse and Linux Mint. Krita 4.4.8 appimage works, but 5.0.2 does not. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 448613] New: Android render image sequence fails
https://bugs.kde.org/show_bug.cgi?id=448613 Bug ID: 448613 Summary: Android render image sequence fails Product: krita Version: 5.0.2 Platform: Android OS: Android 8.x Status: REPORTED Severity: normal Priority: NOR Component: Animation Assignee: krita-bugs-n...@kde.org Reporter: knowz...@pokemail.net Target Milestone: --- SUMMARY When you try to render an image sequence on Android in Krita 5, it leads to an error: Failed to render animation frames! Output files are incomplete STEPS TO REPRODUCE 1. Make a simple animation, 2 frames even 2. Render animation and select image sequence and output folder OBSERVED RESULT Fails to render EXPECTED RESULT rendering the frames SOFTWARE/OS VERSIONS Android 8.1 - Samsung Galaxy A10 2016 ADDITIONAL INFORMATION Regular export as to same folder works, so it isn't an issue saving the content or a permissions issue. I also tried it on my ChromeOS Android device, and it does work properly there. Another user has reported same issue with their Samsung S7 tablet. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 446320] Crash when rendering to GIF
https://bugs.kde.org/show_bug.cgi?id=446320
--- Comment #3 from Know Zero ---
(In reply to Know Zero from comment #1)
> (In reply to Halla Rempt from comment #0)
> > a81d83d340ea0fa0fcee652963faf262b92a07c3
> >
> > After rendering to GIF, krita asserts:
> >
> > krita(2144656)/(default) kis_assert_common: ASSERT (krita): "m_process ==
> > nullptr" in file
> > /home/halla/dev/krita/libs/ui/animation/KisFFMpegWrapper.cpp, line 47
> >
> > See
> > https://krita-artists.org/t/krita-next-crashes-when-rendering-animations-as-
> > gif/32651
>
> When gif is created, it is done in 2 parts. First to generate the palette.
> Then using the palette to generate the final file. thus it fails the
> m_process == nullptr as the pointer still holds the last process.
>
> Adding m_process.reset()
>
> after
>
> 158 if (processResults->finish == true) {
>
> should fix it.
Looking at:
https://bugs.kde.org/show_bug.cgi?id=442578
It seems the goal was to prevent manually doing the cleanup. If that is the
case, other options include creating a separate FFMpegWrapper to run the
palette, or merge the palettegen and paletteuse into 1 command.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 446320] Crash when rendering to GIF
https://bugs.kde.org/show_bug.cgi?id=446320
Know Zero changed:
What|Removed |Added
CC||knowz...@pokemail.net
--- Comment #1 from Know Zero ---
(In reply to Halla Rempt from comment #0)
> a81d83d340ea0fa0fcee652963faf262b92a07c3
>
> After rendering to GIF, krita asserts:
>
> krita(2144656)/(default) kis_assert_common: ASSERT (krita): "m_process ==
> nullptr" in file
> /home/halla/dev/krita/libs/ui/animation/KisFFMpegWrapper.cpp, line 47
>
> See
> https://krita-artists.org/t/krita-next-crashes-when-rendering-animations-as-
> gif/32651
When gif is created, it is done in 2 parts. First to generate the palette. Then
using the palette to generate the final file. thus it fails the m_process ==
nullptr as the pointer still holds the last process.
Adding m_process.reset()
after
158 if (processResults->finish == true) {
should fix it.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 438312] Restarting kwin_x11 forgets activities assigned to windows
https://bugs.kde.org/show_bug.cgi?id=438312 Know Zero changed: What|Removed |Added CC||knowz...@pokemail.net --- Comment #2 from Know Zero --- (In reply to Oded Arbel from comment #0) > SUMMARY > When kwin is restarted (due to crash or on purpose - I some times need to do > that on X11 to fixed kwin display issues), the assignment of windows to > virtual desktop is retained, but assignment of activities is lost and all > windows become "show on all activities". I can also confirm it. And still continues to be an issue in 5.23.2 Yes, this it is really annoying and makes activities hard to use as they start getting in your way when the windows just hang there. It was so annoying I made a script to fix it manually: https://github.com/KnowZero/Rebind-KWin-Activities But an official fix would be nice. PS I fix most window display issues by just switching the compositor from opengl 2 to 3 and back. Fixes most issues without restarting kwin. But sometimes kwin just crashes, especially when developing. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445058] New: kwin interactive console does not work
https://bugs.kde.org/show_bug.cgi?id=445058 Bug ID: 445058 Summary: kwin interactive console does not work Product: kwin Version: 5.23.2 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: knowz...@pokemail.net Target Milestone: --- SUMMARY Using the plasma-interactiveconsole --kwin , I go to kwin option on top. Then copy and paste the examples from here: https://develop.kde.org/docs/plasma/kwin/#quick-start-desktop-console They don't work. It says executed but nothing shows. I tried simple console.log or print and they also don't work. I even tried a syntax error by typing gibberish and it still says executed with nothing outputting. The Plasma tab works, but it doesn't have access to the kwin api. STEPS TO REPRODUCE 1. Launch plasma-interactiveconsole --kwin 2. Pick kwin in the top tab 3. write anything 4. Execute OBSERVED RESULT Executing script at Saturday, November 6, 2021 12:16:10 AM EDT Runtime: 11ms But nothing shows up EXPECTED RESULT Any output! SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSuse Leap 15.3 KDE X11 KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 444746] New: Ability to display activity manager on the right side
https://bugs.kde.org/show_bug.cgi?id=444746 Bug ID: 444746 Summary: Ability to display activity manager on the right side Product: systemsettings Version: 5.23.2 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_activities Assignee: ivan.cu...@kde.org Reporter: knowz...@pokemail.net CC: plasma-b...@kde.org Target Milestone: --- SUMMARY Currently, when the activity manager widget is opened, it only opens on the left side. And only way to have it opened on the right side it seems is switching from left to right, to right to left. It would be nice to have a settings to choose which side you wish it to open (right or left) regardless of your language as I have the panel on the right, but the activity manager opens on the left. And only current way to is to rewrite the files on boot. It would help if this was actually a configurable option or setting that doesn't get overridden every update. Thanks -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442328] Find ffmpeg automatically from PATH
https://bugs.kde.org/show_bug.cgi?id=442328
Know Zero changed:
What|Removed |Added
CC||knowz...@pokemail.net
--- Comment #5 from Know Zero ---
(In reply to healer.harie from comment #3)
> It's strange that you mentioned that it should already work. Was this
> behaviour replicatable in other machine (including linux and macOS) for
> 5.0.0beta1?
>
> I did have krita v4.4.7 in an other Windows machine (long ago), where I've
> added an additional rule of the path of ffmpeg (C:\Program Files\fftools) to
> the environment variable, PATH. The CMD does recognize the `ffmpeg` command,
> but krita don't automatically find it.
>
> I ran krita.com, and tried to open the "Render Animation", the log contained
> like:
> ```
> ...
> Qprocess: Destroyed while process ("C:\\Program Files\\fftools\\ffmpeg.exe")
> is still running.
>
> ```
>
> It seems that somehow, krita knows ffmpeg.exe exist and its location but the
> FFmpeg text box is still empty.
>
> But, if I manually execute ffmpeg.exe (by clicking the ffmpeg executable),
> Krita will eventually fill up the location of ffmpeg and the "Qprocess log"
> stops appearing. It remember this even if I restart Krita again and again,
> but do I restart the computer itself, is when it will be back to normal and
> I had to execute ffmpeg again. This does not solve the problem.
>
> On a side note, I see that proposedPaths is written to some stream
> https://github.com/KDE/krita/blob/fd7ec51dd1e66fc3aa92a6021036fb711ba69003/
> libs/ui/animation/KisFFMpegWrapper.cpp#L365, where could I possibly find
> this file?
It's the timeout issue that should have been fixed in:
https://invent.kde.org/graphics/krita/-/commit/123c302c722376870ed6def5a873b046576882b8
Try the latest nightly build and it should work.
This is a duplicate of:
https://bugs.kde.org/show_bug.cgi?id=441435
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 441435] Can't add ffmpeg as path
https://bugs.kde.org/show_bug.cgi?id=441435 --- Comment #13 from Know Zero --- (In reply to Ahab Greybeard from comment #12) > It would have been the 4.4 release essential build from the .zip package. > I didn't try the git essentials until after the crash. > From then, neither of them gave a crash. > > When I have time, I'll try things to make it crash again. > > If it's a separate issue, should the crash be reported in a new bug report? Yes, it would be a separate issue with its own ticket. If possible, set ENV: QT_LOGGING_RULES="krita*=true" during testing and have Microsoft's DebugView running. This would output more detailed logs. Also, check to see when it crashes if the frames were exported or not (to know if the crash happened on the export frames or on the encoding part) PS merge request to fix the remaining issue for this bug has been made: https://invent.kde.org/graphics/krita/-/merge_requests/1026 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441435] Can't add ffmpeg as path
https://bugs.kde.org/show_bug.cgi?id=441435 --- Comment #11 from Know Zero --- The issue with recorder is the same, at line 80 of /krita/plugins/dockers/recorder/recorder_export.cpp 1000 needs to be changed to 5000. That said, checkFfmpeg function should probably be changed to use the KisFFMpegWrapper's findFFMpeg for consistency. As for the crash, that is a separate issue. But can you clarify exactly which version of ffmpeg you used as you mentioned multiple. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441435] Can't add ffmpeg as path
https://bugs.kde.org/show_bug.cgi?id=441435 --- Comment #8 from Know Zero --- I think I figured out the underlining issue. It wasn't a problem of gyan build or btbn builds. But simply me using 4.4 vs snapshot builds. And the culprit is Windows Defender. My guess what is going on is that since snapshot builds are always new, Windows Defender spends time carefully scanning them. The 4.4 builds on the other hands are known as many more people use them, so Windows Defender just lets them through with less caution. If I exclude the directory of the snapshot ffmpeg versions, it loads up quickly just fine just like the 4.4 versions. I am not sure why the com load faster than from the exe though, maybe windows defender is more picky if the caller is an exe or maybe some other underlining thing at play. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441435] Can't add ffmpeg as path
https://bugs.kde.org/show_bug.cgi?id=441435 --- Comment #7 from Know Zero --- (In reply to Eoin O'Neill from comment #6) > I spent time getting a windows build up and running. For whatever reason, I > couldn't reproduce this on my machine even with insanely low timeout values. > It works as expected. > > I've increased the timeout value as KnowZero has suggested. Please reopen > and assign me again if the issue continues on tomorrow's nightly build. Eoin, when you tested, did you try the Gyan build mentioned? Cause I was able to replicate the issue in my VM. To summarize: At 1000 timeout: BtbN build - no issue Gyan build - issue when using krita.exe, no issue when using krita.com Maybe some sort of startup delay or delay on getting the entire buffer? Since I can replicate it, I can look into it in more detail if the 5000ms timeout isn't ideal. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 441435] Can't add ffmpeg as path
https://bugs.kde.org/show_bug.cgi?id=441435 Know Zero changed: What|Removed |Added CC||knowz...@pokemail.net --- Comment #3 from Know Zero --- (In reply to Halla Rempt from comment #2) > Emmet, Eoin: can you take a look? Halla, it seems the issue is the QProcess gets killed before returning data back when running Krita.exe and using Gyan's package on Windows (Running it as krita.com works fine) The solution is changing the timeout from 1000 to 5000 to give it more time. That would be in: krita/libs/ui/animation/KisFFMpegWrapper.cpp on both line 409 and 423 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440944] New: Crash on new document from clipboard for PNGs
https://bugs.kde.org/show_bug.cgi?id=440944 Bug ID: 440944 Summary: Crash on new document from clipboard for PNGs Product: krita Version: nightly build (please specify the git hash!) Platform: Appimage OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: knowz...@pokemail.net Target Milestone: --- SUMMARY I tried copying a PNG file from chromium and create a new document, and it crashes for the latest appimage. There is not much in the log. Copy and paste works fine if the document already exists. I tried from kgwenview to see if it is a chromium thing and same issue. For the master build, it doesn't crash. But I just get a blank canvas. That said, I will note a difference in GUI as well (for the master build). When I click OK on the create from clipboard for JPGs, it asks me if I want to import it as web. For PNGs, after hitting OK, it gives a context menu asking if I want to import it into a new layer, file layer (same context menu when you do regular copy and paste) Though it seems that overall there is a different UI for JPG imports and PNGs. Cause even if I copy and paste into an existing document, a JPG, it gives a dialog while PNG gives the context menu. STEPS TO REPRODUCE 1. Copy a PNG into clipboard 2. File->new->from clipboard->OK OBSERVED RESULT Nightly appimage build: crash Master: Blank document EXPECTED RESULT The PNG to show on the document SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSuse 15.3 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Appimage is latest: e89467b Master is from Aug 6th: 527355ca -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440139] Resizing watercolor brush leads to crash on latest appimage
https://bugs.kde.org/show_bug.cgi?id=440139 Know Zero changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #5 from Know Zero --- This issue seems to be fixed. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440139] Resizing watercolor brush leads to crash on latest appimage
https://bugs.kde.org/show_bug.cgi?id=440139
Know Zero changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #4 from Know Zero ---
I don't think the issue is fully fixed :(
It still crashes when trying to resize a water color brush. (or to be more
specific, when upgrading from Krita 4, fresh seems to be fine)
Here is from the latest appimage:
Krita Version: 5.0.0-prealpha (git a3253a2), Qt version compiled: 5.12.11,
loaded: 5.12.11. Process ID: 26423
-- -- -- -- -- -- -- --
24 Jul 2021 16:33:00 -0400: Style: fusion. Available styles: Windows, Fusion
24 Jul 2021 16:33:00 -0400: Database is up to date. Version: 0.0.10, created by
Krita 5.0.0-prealpha, at Tue Jul 20 03:36:31 2021
24 Jul 2021 16:33:00 -0400: Could not retrieve md5 for
resourcepaintoppresets/Special_dyna_dots.kpp
24 Jul 2021 16:33:00 -0400: SAFE ASSERT (krita): "retval" in file
/home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/resources/KisResourceCacheDb.cpp,
line 1459
24 Jul 2021 16:33:00 -0400: Could not add
resourcea63767fe-c3b9-4f98-8582-be74fffbdd0f_style
24 Jul 2021 16:33:16 -0400: Created image "Unnamed", 1650 * 900 pixels, 72 dpi.
Color model: 8-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc).
Layers: 1
KRITA DID NOT CLOSE CORRECTLY
I also updated my master to see if it is just the appimage, and it also crashed
but looking at the QT logs:
krita.lib.store: KOStore "brushes/watercolor.gih" "brushes/watercolor.gih"
krita.lib.store: Opening for reading "brushes/watercolor.gih"
[RESOURCE] Name: "Watercolor" Version: 0 Filename: "watercolor.gih"
MD5: "ab0f2533f70f76314711899bec6b34cb" Type: QPair("brushes","gbr_brushes")
Valid: true Storage:
"/home/e/.local/share/krita/Krita_4_Default_Resources.bundle"
krita.lib.resources: resourceSelected: preset QSharedPointer(0x4712150) "1"
krita.ui: setPreviousPaintOpPreset "" ("paintbrush" )
global for filename "watercolor.gih" rowcount 256
[RESOURCE] Name: "Watercolor" Version: 0 Filename: "watercolor.gih"
MD5: "ab0f2533f70f76314711899bec6b34cb" Type: QPair("brushes","gbr_brushes")
Valid: true Storage:
"/home/e/.local/share/krita/Krita_4_Default_Resources.bundle"
krita.plugins: Unknown transform parameter : ""
krita.plugins: Unknown transform parameter : ""
global for filename "abominable_snowman.png" rowcount 256
[RESOURCE] Name: "abominable_snowman" Version: 0 Filename:
"abominable_snowman.png" MD5: "c605fb1974497a2974efa42352a88abe" Type:
QPair("brushes","png_brushes") Valid: true Storage:
"/home/e/.local/share/krita/Krita_4_Default_Resources.bundle"
global for filename "watercolor.gih" rowcount 256
[RESOURCE] Name: "Watercolor" Version: 0 Filename: "watercolor.gih"
MD5: "ab0f2533f70f76314711899bec6b34cb" Type: QPair("brushes","gbr_brushes")
Valid: true Storage:
"/home/e/.local/share/krita/Krita_4_Default_Resources.bundle"
global for filename "watercolor.gih" rowcount 256
[RESOURCE] Name: "Watercolor" Version: 0 Filename: "watercolor.gih"
MD5: "ab0f2533f70f76314711899bec6b34cb" Type: QPair("brushes","gbr_brushes")
Valid: true Storage:
"/home/e/.local/share/krita/Krita_4_Default_Resources.bundle"
KCrash: Application 'krita' crashing...
---
Seeing Krita 4 in there, I tried making a .home folder for the appimage to
start fresh. And it seems to work fine then.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 440139] Resizing watercolor brush leads to crash on latest appimage
https://bugs.kde.org/show_bug.cgi?id=440139 --- Comment #1 from Know Zero --- I did a test in my KDE OpenSuse 15.3 dev environment updating it to latest, and it also crashed. It did not crash back at commit c81ba5b3 which was 2 days ago. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440139] New: Resizing watercolor brush leads to crash on latest appimage
https://bugs.kde.org/show_bug.cgi?id=440139 Bug ID: 440139 Summary: Resizing watercolor brush leads to crash on latest appimage Product: krita Version: nightly build (please specify the git hash!) Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: knowz...@pokemail.net Target Milestone: --- SUMMARY Krita crashes on latest appimage when trying to resize a watercolor brush STEPS TO REPRODUCE 1. Select a water brush like j)Watercolor texture 2. Then try to resize it via the top resize bar OBSERVED RESULT Crash Krita Version: 5.0.0-prealpha (git 63be085), Qt version compiled: 5.12.11, loaded: 5.12.11. Process ID: 17567 -- -- -- -- -- -- -- -- 22 Jul 2021 02:22:18 -0400: Style: fusion. Available styles: Windows, Fusion 22 Jul 2021 02:22:19 -0400: Database is up to date. Version: 0.0.10, created by Krita 5.0.0-prealpha, at Tue Jul 20 03:36:31 2021 22 Jul 2021 02:22:19 -0400: Could not retrieve md5 for resourcepaintoppresets/Special_dyna_dots.kpp 22 Jul 2021 02:22:19 -0400: SAFE ASSERT (krita): "retval" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/resources/KisResourceCacheDb.cpp, line 1459 22 Jul 2021 02:22:19 -0400: Could not add resourcea63767fe-c3b9-4f98-8582-be74fffbdd0f_style 22 Jul 2021 02:22:24 -0400: Created image "Unnamed", 1650 * 900 pixels, 72 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 1 22 Jul 2021 02:22:38 -0400: SAFE ASSERT (krita): "brush" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/brush/kis_predefined_brush_factory.cpp, line 37 KRITA DID NOT CLOSE CORRECTLY EXPECTED RESULT SOFTWARE/OS VERSIONS AppImage 63be085 on both Mint and on OpenSuse 15.3 ADDITIONAL INFORMATION This does not happen on older Appimage 4c233e3 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 438900] Text DPI issue on KDE Plasma
https://bugs.kde.org/show_bug.cgi?id=438900 --- Comment #4 from Know Zero --- (In reply to Dmitry Kazakov from comment #2) > Well, all Krita 4.x versions had a problem with font size. To correct my last statement a bit, probably a checkbox for Krita 5 would be confusing for new documents. So probably this setting would have to be for individual documents or all documents originally made in Krita 4. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 438900] Text DPI issue on KDE Plasma
https://bugs.kde.org/show_bug.cgi?id=438900 --- Comment #3 from Know Zero --- (In reply to Dmitry Kazakov from comment #2) > Well, all Krita 4.x versions had a problem with font size. They used display > DPI for font rendering, so the font size saved into the file depended on the > computer that was used for creating this document. > > In Krita 5 I have fixed this problem. On loading it converts the font size > into the correct value and saves into the document. Opening this document on > any PC with Krita 5.x will show the correct font size whatever the display > resolution used. > > Sadly, versions of Krita 4.x don't know about this fix, so they will show > the document differently after it is saved using Krita 5. > > So the solution is: don't open the .kra files with text created with Krita 5 > in older versions of Krita :( But what about the documents created with Krita 4? When people open them, the font will seem fine in Krita 5. But when they edit the font or save the document and re-open them later, they will find the font size changed without them knowing that it did. So at the very least, there should be some sort of warning if you open a Krita 4 document with Text shapes in them that explains the issue and what to do (Cause people will not even understand WHY that is the case or what was the original font size to begin with). Or is it possible to keep the Krita 4 sizes in Krita 5 as long as the original document was made in Krita 4 with the option of converting to Krita 5? For myself I just made a python plugin that divides the font by 0.75 on all fonts and rebuilds them. So 10pt becomes 13.3pt, but that isn't something most average people will know. There will be a ton of complaints how their documents fonts broke. Not to mention, what purpose does the high DPI workaround serve if it doesn't work on Krita 5 documents? Maybe an extra checkbox to enable it for Krita 5 documents? And the warning can point to this setting? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 438900] New: Text DPI issue on KDE Plasma
https://bugs.kde.org/show_bug.cgi?id=438900 Bug ID: 438900 Summary: Text DPI issue on KDE Plasma Product: krita Version: git master (please specify the git hash!) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tool/Text Assignee: krita-bugs-n...@kde.org Reporter: knowz...@pokemail.net Target Milestone: --- SUMMARY When you open an krita 4.4.x file in Krita 5 on KDE Plasma 5, it seems to open the files fine. But when you save the files, the font size changes without the user knowing. The merge request mentions the DPI setting, but most users wouldn't know it exists and would simply find it broken. Not to mention, that setting doesn't work on KDE Plasma for 5.0 saved files. (it works for 4.4.x files in 5.0, but the moment you save them, it won't work anymore) This doesn't seem to be a problem on Windows or Ubuntu Unity (when testing on VM as the text loaded fine as far as I saw without any changes) Also a minor issue to note: The tooltip on the DPI gives different messages depending if you hover over the label or the textbox. STEPS TO REPRODUCE 1. Save a file in Krita 4.4.x while using KDE Plasma 5 2. Open it in Krita 5 and save the file as a new file, then close and reopen it. The fonts are wrong.(you can also just edit the text on the spot and font will change) 3. Change the DPI setting and try again OBSERVED RESULT Wrong font size EXPECTED RESULT Right font size SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSuse Leap 15.2 KDE 5.22 (QT 5.15) and Kubuntu 20.04 LTS via VM. X11 sessions for both. This also happens via the nightly appimage versions (4c233e3). ADDITIONAL INFORMATION This is probably related to the fix for Bug 404011. -- You are receiving this mail because: You are watching all bug changes.
