[krita] [Bug 404782] Incremental Backup is not of Current Document State
https://bugs.kde.org/show_bug.cgi?id=404782 --- Comment #8 from Kenneth Evans --- >> Since this works as Deevad explained, we're not going to change that. That's your choice. I couldn't follow the #314214 link, so I did my own test: New Document, Draw A, F4. Asks for File name, have one file with A. Erase, Draw B, F4. Document has B, 000 has A. Erase, Draw C, F4. Document has C, 000 has A, 001 has B. Erase, Draw D, F4. Document has D, 000 has A, 001 has B, 002 has C. Erase, Draw E, Ctrl-S Document has E, 000 has A, 001 has B, 002 has C. F4 Document has E, 000 has A, 001 has B, 002 has C, 003 has E. I see you corrected the typo. My other suggestion is to not say "Backup the original file you loaded". The meaning of loaded is completely unclear. What it appears to do is backup from what you last saved. If you haven't saved, there is no incremental. (Yes, it's a little hard to explain correctly, but I think you have an obligation to say it correctly in the documentation.) [I would guess a lot of users assume it works as I originally thought. It's not readily apparent what it is actually doing. I've been using it a long time myself, and didn't know until now. I may have been confused when using backups, but I apparently recovered. It doesn't happen often, and I don't remember.] It looks like I can make it do what I want by saving (Ctrl-S), then incremental (F4). Just have to remember that. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404782] Incremental Backup is not of Current Document State
https://bugs.kde.org/show_bug.cgi?id=404782 --- Comment #6 from Kenneth Evans --- And thinking about it, it's probably not when you loaded (opened?) the file. That could have been a week ago in my case. I tend to leave Krita up when I'm working on something. I don't do any loading, just saving. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404782] Incremental Backup is not of Current Document State
https://bugs.kde.org/show_bug.cgi?id=404782 --- Comment #5 from Kenneth Evans --- I looked at it. There is a typo "the your". I haven't had time to check but hopefully Save, then Incremental Backup will do what I want. If so, you could add that to the explanation. It's pretty cryptic as is. Though technically accurate, it's not especially clear (IMHO) that you will be getting an old state. The idea after all is to help the user, not just state the facts. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404782] Incremental Backup is not of Current Document State
https://bugs.kde.org/show_bug.cgi?id=404782 --- Comment #3 from Kenneth Evans --- (This is the same issue as #401795.) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401795] Save Incremental Backup has wrong Modified Date
https://bugs.kde.org/show_bug.cgi?id=401795 --- Comment #3 from Kenneth Evans --- What a surprise! Who would ever think incremental backup was backing up with some state from the past. I don't know of anything else that works that way, and it certainly isn't what I want or thought I was getting. I want to save a snapshot of my work and continue working on the same file. I can only speak for myself, but it's really hard for me to see why anyone would want it to work as it does. And there is no option do do what I want, save a snapshot and continue working on the same file. The documentation says: Save incremental version Save as a new version of the same file with a number attached. Save incremental Backup Make a backup file without leaving the working file. If you insist on the incremental backup not being a backup of your current work, then please make it clear in the documentation what it is doing. Based on past experience and your reaction here, I don't expect you will fix it, but it really is a gotcha and SHOULD be fixed. (This is the same issue as #404782.) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404782] Incremental Backup is not of Current Document State
https://bugs.kde.org/show_bug.cgi?id=404782 --- Comment #2 from Kenneth Evans --- What a surprise! Who would ever think incremental backup was backing up with some state from the past. I don't know of anything else that works that way, and it certainly isn't what I want or thought I was getting. I want to save a snapshot of my work and continue working on the same file. I can only speak for myself, but it's really hard for me to see why anyone would want it to work as it does. And there is no option do do what I want, save a snapshot and continue working on the same file. The documentation says: Save incremental version Save as a new version of the same file with a number attached. Save incremental Backup Make a backup file without leaving the working file. If you insist on the incremental backup not being a backup of your current work, then please make it clear in the documentation what it is doing. Based on past experience and your reaction here, I don't expect you will fix it, but it really is a gotcha and SHOULD be fixed. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404782] New: Incremental Backup is not of Current Document
https://bugs.kde.org/show_bug.cgi?id=404782 Bug ID: 404782 Summary: Incremental Backup is not of Current Document Product: krita Version: 4.1.7 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: grave Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- I had been working on a document and found I had selected the wrong size. I then: 1. Did an incremental save of the current document. 2. Increased the size. 3. Did an another incremental save. On looking at the saved versions, both had the same size, the smaller one. This is disturbing, and it is good I checked. My next incremental save was the correct size. I may have done a plain save in between. I am not sure what it is saving in an incremental save, but it certainly isn't the current state of the document. The only reason I noticed it was not correct is from the size change. How else would you tell for sure in the usual case where the size doesn't change. I submitted another issue #401795 about the date on incrementally-saved documents being wrong. (Nothing has been done.) It looks there are several problems with incremental save. Both issues indicate it is saving some old state, not the current one. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404782] Incremental Backup is not of Current Document State
https://bugs.kde.org/show_bug.cgi?id=404782 Kenneth Evans changed: What|Removed |Added Summary|Incremental Backup is not |Incremental Backup is not |of Current Document |of Current Document State -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400256] Make Gradient Editors Work Consistently
https://bugs.kde.org/show_bug.cgi?id=400256 --- Comment #9 from Kenneth Evans --- I looked at this again this morning. I am still confused as to what is happening. Perhaps there is no way to save your edits. In the best of all possible worlds the edit dialog would have Save and Cancel. It would be nice to be able to see the XML, too. The documentation is not helpful as to what this dialog does. The only thing that is working for me is to edit the gradients elsewhere and manually put them in the gradients directory in the settings -- not what you call user friendly ;-) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400256] Make Gradient Editors Work Consistently
https://bugs.kde.org/show_bug.cgi?id=400256 --- Comment #8 from Kenneth Evans --- I even tried renaming it, and it didn't save it (nor modify ko_gradients.blacklist). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400256] Make Gradient Editors Work Consistently
https://bugs.kde.org/show_bug.cgi?id=400256 --- Comment #7 from Kenneth Evans --- More problems. I edit a stop gradient. It changes in the Gradients panel, but it isn't saved. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400256] Make Gradient Editors Work Consistently
https://bugs.kde.org/show_bug.cgi?id=400256 --- Comment #6 from Kenneth Evans --- I just tried using the segmented gradient editor. It did not seem to work well at all. On clicking a stop, it usually did not change the colors to be edited. I was trying to create a grayscale gradient with five values, and it was very frustrating. I would make a change and something weird would happen, apparently because I was not editing the stop I had clicked. The stop doesn't seem to get highlighted either. I could move the stops, but not make the colors change reliably, and often not at all. I ended up figuring out the file format and created the gradient in a text editor. (I wanted 5 bars of increasing gray values to get values from an image using a Gradient Map.) That worked, to some extent at least. The Gradient icon in the tool bar showed my gradient correctly (5 bars of increasing gray values). However, the gradient editor itself showed a continuous grayscale, not blocks, and attempting to use it as a Filter Mask with Gradient Map also had a continuous grayscale. BTW the document ion does not say to right click the bar to split the gradient. Took a while to figure that out. [After spending all that time, I WAS able to get what I wanted with a Stop (SVG) gradient without having to do it in an editor.] I'm not doing well with gradients. ;-) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401795] New: Save Incremental Backup has wrong Modified Date
https://bugs.kde.org/show_bug.cgi?id=401795 Bug ID: 401795 Summary: Save Incremental Backup has wrong Modified Date Product: krita Version: 4.1.5 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- SUMMARY Save Incremental Backup (F4) does not have the correct modified date. I am not sure what it is using, but it is different from the Created and Accessed dates, which are the current time. I just did an incremental backup, and it has a Modified Date of yesterday, in fact. Very confusing and seems wrong. It makes it difficult to determine which backup I am looking for. Yes, I can apparently look at the Creation date, now that I know, but Windows typically uses the Date modified in Explorer, so that was not obvious and is not convenient. And it's hard to see how a Modified Date that is not at the time it was saved is correct. STEPS TO REPRODUCE 1. Work on a drawing. 2. F4 3. OBSERVED RESULT Modified date is in the past. EXPECTED RESULT Modified date is when I saved it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401634] Brush Disappears from Presets Filtered by a Tag After Override Brush
https://bugs.kde.org/show_bug.cgi?id=401634 --- Comment #5 from Kenneth Evans --- Just for the record. I added another pattern from the file system. The one just previously added was not the one I thought it was, so I deleted it via the trash can icon in the Pattern properties. Krita crashed. On restart, the deleted pattern was not there. However the original problem brush has a name like f)_Bristles-3_Large_Smooth_Texture(f)_Bristles-3_Large_Smooth_Texture_backup_2018-12-02-173620.kpp) and the new test brush has a name like f)_Bristles-3_Large_Smooth_Test(f)_Bristles-3_Large_Smooth_Test_backup_2018-12-02-170756.kpp). So it is all screwed up. I want to use this brush and don't want it causing other problems, so I am going to try to clean it up as I said and start over, rather than waiting for your response. Given you are on another platform and using a different version of Krita, I don't see much prospect for anything useful happening in any event. Sorry. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401634] Brush Disappears from Presets Filtered by a Tag After Override Brush
https://bugs.kde.org/show_bug.cgi?id=401634 --- Comment #4 from Kenneth Evans --- Later: It happened again. I continued working from where I left off above. I changed the pattern in the new brush, did Overwrite Brush, and it behaved ok. This pattern was imported from the file system, not from the Digital Atelier patterns. I then changed the pattern in the brush I was using yesterday to the same pattern, did Overwrite brush, and it disappeared from the brushes filtered by Oil (where it was when I changed the texture, and where it has been since I thought I got it straightened out). So this brush is clobbered somehow. I can, of course, delete all the brushes I recently created from f) Bristles-3 Large Smooth, clean out the kis_paintoppresets.blacklist, and start over, but I will leave it for now in case you have some suggestions to try to track this down. The problem does seem to be happening somewhat reproducibly with this brush. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401634] Brush Disappears from Presets Filtered by a Tag After Override Brush
https://bugs.kde.org/show_bug.cgi?id=401634 --- Comment #3 from Kenneth Evans --- (I wasn't imagining it.) I tried what you did, keeping notes on just what happened. Per my second message, I had got the brush apparently straightened out yesterday by restarting Krita a few times and doing nothing but look at the brush. (I did open an image.) These are the steps I took today. 1. Restarted Krita again, and opened the image. 2. Verified new brush is tagged as Oil. (I am only using the Brush Panel, not a Docker for now. I am also forgetting about the KE tag for now.) 3. For f) Bristles-3 Large Smooth I again added a texture. The texture I am using is from Digital Atelier (DA_Oil_Primed DMF cotten mid.png), which means it is in a bundle, not loose in the file system. 4. I saved it as a new brush. 5. I tagged it as Oil, and it appeared when filtered by Oil. 6. I then tested it. It did not have texture, even though I had checked the Pattern checkbox. (You can't, in fact, pick a pattern unless it is checked.) 7. I went back to the Brush Panel and checked Pattern again. (It remembered the pattern used, just not the checkbox.) 8. I tested it, and it did now have a pattern. 9. I did Overwrite Brush. 10. It remained under the brushes filtered by Oil. 11. I changed the tip size, and tested again. (The tip size changed.) 12. I did Overwrite Brush again. 13. It remained under the brushes filtered by Oil. So I am not reproducing it myself at the moment. I have done nothing else except the few test strokes. It did not handle the pattern correctly, but is not having the tag problem. I was also having trouble yesterday with the pattern properties page working correctly. (And I have also had problems in the past.) I did not document these problems carefully enough to submit an issue. Even though the pattern properties behavior would be a separate issue, it may be this behavior that is causing the behavior with the tags. I don't normally have problems with tags for brushes. In any event it seems to be intermittent. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401634] Brush Disappears from Presets Filtered by a Tag After Override Brush
https://bugs.kde.org/show_bug.cgi?id=401634 --- Comment #1 from Kenneth Evans --- I restarted Krita once again. The brush did not appear with the filter set to Oil. On setting it to All, it did not have the tags set (as it did when I exited). I set them and exited Krita again without doing anything else. On restarting Krita, it appears to be working Ok; that is, the brush has the tags assigned and appears when the tag filter is set to one of them. I haven't tried Override brush again. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401634] New: Brush Disappears from Presets Filtered by a Tag After Override Brush
https://bugs.kde.org/show_bug.cgi?id=401634 Bug ID: 401634 Summary: Brush Disappears from Presets Filtered by a Tag After Override Brush Product: krita Version: 4.1.5 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- SUMMARY I have made a variant of a brush, (f) Bristles-3 Large Smooth, that has Texture. I have assigned two tags, KE and Oil. It appears in the Brush Panel with the presets showing and tags filtered to Oil. If I change a parameter, e.g. Size, and do Overwrite Brush, then it no longer appears in the presets with the tag filter still set to Oil. If I set the tag filter to All, then I see the brush, and it has both tags. I cannot find a way to get it to appear with filter set to Oil, other than by restarting. I have reproduced this twice, restarting Krita in between. STEPS TO REPRODUCE 1. Make a variant of a brush, tag it, and save it. 2. Change a parameter and do Override Brush. 3. OBSERVED RESULT Disappears from presets filtered by the tag where it appeared before the Override but still has the tag. EXPECTED RESULT Stays in the presets filtered by the tag where it appeared before the Override. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 389928] Saving GIH brush doesn't save the "create mask from color" property
https://bugs.kde.org/show_bug.cgi?id=389928 --- Comment #6 from Kenneth Evans --- There is an additional problem with the GIH save operation in that it asks for the name twice, once in the file selection dialog and again in the following options dialog. If you neglect to enter the name in the second one, the file is .gih, not what you entered in the file selection dialog. And you don't notice this at the time. The name in the file selection dialog should be passed to the second dialog. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 389928] Saving GIH brush doesn't save the "create mask from color" property
https://bugs.kde.org/show_bug.cgi?id=389928 --- Comment #5 from Kenneth Evans --- There seems to be more to it than just in saving the GIH. "Use color as mask" is unchecked for the brushes saved in Krita _and_ the default GIH brushes, but the latter work as masks anyway. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 389928] Saving GIH brush doesn't save the "create mask from color" property
https://bugs.kde.org/show_bug.cgi?id=389928 Kenneth Evans changed: What|Removed |Added CC||k...@kenevans.net --- Comment #4 from Kenneth Evans --- I was going to submit this as a bug, but this seems to be the same issue. The bottom line is that GIH files saved in Krita default to not being masks, even if the "Use color as mask" is checked. This happens with some GDquest brushes as well as my own. I am on Krita 4.1.5 on Windows. Here is what I was going to submit. SUMMARY Brushes saved as GIH in Krita with "Use color as mask" checked, default to having this unchecked and don't behave as masks when this brush is selected for the tip. It can be fixed by checking "Use color as mask" for the tip. However, this has to be rechecked every time you go back to this brush. This may be a problem with the GIH save in Krita as other brushes which are GIH files do open as masks but have "Use color as mask unchecked", as well). E.g. bristles_circle_random. I did not test all the GIH brushes. I note ones by GDQuest also have this problem. STEPS TO REPRODUCE 1. Create a GIH file in Krita from, say, the Texture 256x256 Predefined option. 2. Save it as 1 layer Regular or multiple layer Random (either gives the problem), checking the "Use color as mask" option. 3. Import it in the Brush Editor and use it as a tip. OBSERVED RESULT Shows white background. (Can see in the preview.) EXPECTED RESULT Acts as a mask. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398509] Request for Outline Tool
https://bugs.kde.org/show_bug.cgi?id=398509 --- Comment #9 from Kenneth Evans --- Looking back at this again, the Polygon Tool does just what you want (draws, then fills) except that it does a polygon rather than a continuous outline. It would be nice to have a Outline Tool version. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398509] Request for Outline Tool
https://bugs.kde.org/show_bug.cgi?id=398509 --- Comment #8 from Kenneth Evans --- I tried the Freehand Path Tool, or more accurately tried to try it. The Tool Options are Fill and Outline (not Stroke). There are also Pencil settings. None of this is explained in the manual link you gave. AFAICT it draws an outline using the current brush and then fills it after it is done, as you said. This is a problem if the current brush is not a thin line. And you would have to switch from the Gpen, then switch to this tool, and then switch both back. See my earlier comment, "... you are drawing all the time, not doing UI things, which keeps your rhythm". It is _not_ useful for this purpose if the current brush has a thick line in any event. But I may not understand it. The manual for it is not helpful, and I didn't find anything Googling. In addition it seems to be buggy. I got an x-out cursor saying I could not draw on my layer (with no error message or explanation) after a couple of tries. I only got rid of this by restarting Krita. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400177] Scale to New Size Doesn't Do Arithmetic Right
https://bugs.kde.org/show_bug.cgi?id=400177 --- Comment #2 from Kenneth Evans --- I don't think it is a duplicate. The other issue is about print sizes and a possible limit for print only. This one has to do with imprecise calculations of image size. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398509] Request for Outline Tool
https://bugs.kde.org/show_bug.cgi?id=398509 --- Comment #6 from Kenneth Evans --- I have been using Clip Studio Paint for some inking, mostly because of this feature. The fill feature really works well there. In addition I am comfortable with how it works in CSP. In fairness, I just tried the Shapes Fill brush in Krita, enough to get at least partially comfortable with inking with it in Krita. After this experimentation, the main problem I see with the Shapes Fill brush is that it fills as you go and hence frequently covers up your sketch. Other than that it seems to suffice. I suppose I could get used to it. I _would_ like to use Krita for everything. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400256] Cannot Remove Stops in Gradient Editor
https://bugs.kde.org/show_bug.cgi?id=400256 --- Comment #4 from Kenneth Evans --- As stated, I tried that. They just piled up at the end. In some cases it looked like they were gone, but they were just on top of each other. I spent a fair amount of time trying, including several restarts. If there is a trick to it, I didn't find it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400256] Cannot Remove Stops in Gradient Editor
https://bugs.kde.org/show_bug.cgi?id=400256 --- Comment #1 from Kenneth Evans --- Meant to say either way gives a hand cursor that closes. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400256] New: Cannot Remove Stops in Gradient Editor
https://bugs.kde.org/show_bug.cgi?id=400256 Bug ID: 400256 Summary: Cannot Remove Stops in Gradient Editor Product: krita Version: 4.1.5 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- SUMMARY I cannot remove stops in the gradient editor. According to the documentation, you right click to remove them. Either right or left clicking gives a cursor that closes. I have tried double clicking, dragging them to the ends, and other things. I have found no way to remove them (except by going to the file and editing the SVG). I am using stop gradients. I have not checked segmented gradients. STEPS TO REPRODUCE 1. Add a stop 2. Right click to remove it 3. OBSERVED RESULT Doesn't get removed. EXPECTED RESULT Gets removed. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398509] Request for Outline Tool
https://bugs.kde.org/show_bug.cgi?id=398509 --- Comment #4 from Kenneth Evans --- For the record, I just discovered the Shapes Fill brush sort of does this. However, it would still be nice to have an Outline Tool. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400177] New: Scale to New Size Doesn't Do Arithmetic Right
https://bugs.kde.org/show_bug.cgi?id=400177 Bug ID: 400177 Summary: Scale to New Size Doesn't Do Arithmetic Right Product: krita Version: 4.1.5 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Resize/Scale Image/Layer Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Created attachment 115838 --> https://bugs.kde.org/attachment.cgi?id=115838=edit Screenshot of Scale to New Size Dialog I resized an image to 18" x 12" at 300 dpi. It didn't come out as 5400 x 3600, rather 5405 x 3602. I then tried sizing it to 5400 x 3600, and the size was 17.99" x 11.99". There seems to be an error somewhere. Even if done in float, it should have more precision than this. STEPS TO REPRODUCE 1. With an existing image, attempt to resize it to 18" x 12" @300 dpi. 2. Just look at the dialog. (You don't have to actually do it.) 3. OBSERVED RESULT 5405 x 3602 (or 17.99 x 11.99) EXPECTED RESULT 5400 x 3600 (or 18.00 x 12.00) Image attached of the setting 5400 x 3600 case. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394139] Color History and Common Patches Show on Wrong Display
https://bugs.kde.org/show_bug.cgi?id=394139 --- Comment #9 from Kenneth Evans --- This is a different problem from the color pickup bug. There it doesn't show at all. Here it shows but in the wrong place. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394131] Issues Creating / Editing Resource Bundles
https://bugs.kde.org/show_bug.cgi?id=394131 --- Comment #2 from Kenneth Evans --- I submitted the second issue as Bug 398685. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398685] New: Creating Resource Bundle Allows Selecting but Silently Does Not Include Existing Brushes
https://bugs.kde.org/show_bug.cgi?id=398685 Bug ID: 398685 Summary: Creating Resource Bundle Allows Selecting but Silently Does Not Include Existing Brushes Product: krita Version: 4.1.1 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Resource Management Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- In either creating or editing resource bundles, I select my Brush Preset and my Brushes. It however, does not use the brush I select in brushes. I _am_ using an existing brush, not one in AppData/Roaming/krita/brushes, but it should still let me use it. If for some reason Krita doesn't want me to use it, there should be a warning when I move it to the right. Silently not including something without letting me know is unfriendly. This was originally reported in Bug 394131, but made a separate issue here. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396490] No color preview with Eyedropper
https://bugs.kde.org/show_bug.cgi?id=396490 --- Comment #4 from Kenneth Evans --- Yes, it does not do that. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396490] No color preview with Eyedropper
https://bugs.kde.org/show_bug.cgi?id=396490 --- Comment #2 from Kenneth Evans --- Zooming isn't viable. You are drawing and want to change the color. Zooming would completely interfere. It doesn't need a key. It needs to show the preview when the eyedropper touches the screen, the same as it does with Ctrl. All drawing programs work that way. Without a preview, you don't know if you have picked the right color. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398509] Request for Outline Tool
https://bugs.kde.org/show_bug.cgi?id=398509 --- Comment #3 from Kenneth Evans --- No, it's really a different thing. I saw it in a webinar by an inker for Marvel comics. For my example the mask might work, but for more elaborate inking it won't. With this tool you are drawing all the time, not doing UI things, which keeps your rhythm. Essentially you just need a pen and this fill tool. You probably have to see it to understand. The webimar is at https://youtu.be/adCeHwgIQi0. I will attach a screenshot from it. Again, it shouldn't be hard to do. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398509] Request for Outline Tool
https://bugs.kde.org/show_bug.cgi?id=398509 --- Comment #2 from Kenneth Evans --- Created attachment 114908 --> https://bugs.kde.org/attachment.cgi?id=114908=edit Professional inking -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398509] New: Request for Outline Tool
https://bugs.kde.org/show_bug.cgi?id=398509 Bug ID: 398509 Summary: Request for Outline Tool Product: krita Version: 4.1.1 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Created attachment 114904 --> https://bugs.kde.org/attachment.cgi?id=114904=edit Example of using a Lasso or Outline Tool with Fill. It would be nice to have an Outline Tool, working like the Polygon Tool but selecting like the Outline Selection Tool. It shouldn't be that hard to implement since the parts are already there in the Polygon Tool and Outline Selection Tool. I have just discovered the Lasso Fill Tool in Clip Studio Paint. (Lasso is their name for what Krita calls Outline.) It is INCREDIBLY useful for inking large areas. You just draw around the area, and it fills. Very fast and easy. You can do this in Krita with the Polygon Tool, but it is slow and the edges are not smooth curves. I am attaching an example. I did it fast, and it may not be the best inking, but it shows what can be done easily with such a tool. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396669] New: Problem with Metadata in JPEG Export
https://bugs.kde.org/show_bug.cgi?id=396669 Bug ID: 396669 Summary: Problem with Metadata in JPEG Export Product: krita Version: 4.1.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- If I export a KRA file as a JPEG and check all the boxes in the Metadata tab, what I gets seems to be non-standard and gives an error in Exiftool, arguably the most used EXIF metadata tool. It will not let me add copyright information, for example. There is no problem if I do not check the Store Document Metadata and Sign with Author Profile Data. Either with or without the information I don't see whatever it is writing for Author Data or anything besides IPTC:Object Name. No EXIF and no XMP. The error I get is from Exiftool is: Warning: Multiple APP1 EXIF records - C:/Users/evans/Documents/Krita/Coons 2018.jpg Error: Format error in file - C:/Users/evans/Documents/Krita/Coons 2018.jpg 0 image files updated 1 files weren't updated due to errors -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 393516] file location for kritarc
https://bugs.kde.org/show_bug.cgi?id=393516 --- Comment #8 from Kenneth Evans --- Thanks. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 393516] file location for kritarc
https://bugs.kde.org/show_bug.cgi?id=393516 --- Comment #6 from Kenneth Evans --- Forget that Explorer can't find it. Forget whether it should be Local or Roaming. It is not where the manual says it is (and it is not where you would expect). I was not able to find it for months. I agree that if fixed, new versions could be made to search possible old places if not found and put it where it belongs. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396490] New: No color preview with Eyedropper
https://bugs.kde.org/show_bug.cgi?id=396490 Bug ID: 396490 Summary: No color preview with Eyedropper Product: krita Version: 4.1.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- I get no preview of what color the Eyedropper is picking. On the other hand, I do get it when using Alt (or Ctrl) with the Brush. (I have an additional keybinding for Alt as well as Ctrl, which is not what I am used to.) The preview is a small square box when using Alt and serves the purpose. There is nothing with the Eyedropper. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 393516] file location for kritarc
https://bugs.kde.org/show_bug.cgi?id=393516 --- Comment #4 from Kenneth Evans --- Correction: (For some reason I did not find it searching all of AppData for "kritarc". in Windows Explorer.) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 393516] file location for kritarc
https://bugs.kde.org/show_bug.cgi?id=393516 Kenneth Evans changed: What|Removed |Added CC||k...@kenevans.net --- Comment #3 from Kenneth Evans --- I have been looking for the kritarc file for months. The manual says: Krita’s preferences are saved in the file kritarc. This file is located in C:\Users\*username*\AppData\Local\krita on Windows. It is not there. I was getting ready to submit a bug, and came across this issue. It is apparently in C:\Users\*username*\AppData\Local, not where the manual says. Who would know? (For some reason I did not find it searching all of AppData for "kritrc". in Windows Explorer.) I agree that is not where it "should" be stored. It should be stored in something application-specific (like where the manual says it is stored). It looks like you should either change it or change the documentation. Thanks. Note: This is under frameworks-kconfig. I don't know what this is. It is happening in Krita 4.1 for me. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 393266] Autosave stops doing its work in certain conditions
https://bugs.kde.org/show_bug.cgi?id=393266 --- Comment #12 from Kenneth Evans --- Thanks. That seems like a good idea. That is not what the manual says, though. It is a bit terse on the subject, as well. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 393266] Autosave stops doing its work in certain conditions
https://bugs.kde.org/show_bug.cgi?id=393266 --- Comment #10 from Kenneth Evans --- Looks like it's being taken care of, but to answer your question, I am saving to Documents\Krita on the local C drive. It is my understanding the autosave files should be in %temp%, which is in the standard place under AppData. There were none there, at least for the last few days. Hopefully, these don't get destroyed when you reopen the file after a crash, as the location is something I may not remember, and it takes a little research to find the location is %temp%. Reopening the last good copy is a natural thing to do first. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 393266] Autosave stops doing its work in certain conditions
https://bugs.kde.org/show_bug.cgi?id=393266 Kenneth Evans changed: What|Removed |Added CC||k...@kenevans.net --- Comment #2 from Kenneth Evans --- Something similar happened to me with 4.1 just now. Krita crashed, and I lost about 45 min. of work. There was no prompt to open the autosave on restart. My Krita is set to autosave every 5 min (probably the default). I have the last .kra file at 8:26 pm. The last kra~ is at 7:45 pm, and there is no kra-autosave.kra in the document directory. This is on a Surface Book with Windows 10 64-bit. On looking at the directory with the file, I see other .kra files that I closed normally have no autosave. In fact, most do not. There are none in %temp% either. There is a krita-opengl.txt file in temp at 9:22, about the time of the crash. The contents are: ntel, Intel(R) HD Graphics 520, 3.0.0 - Build 22.20.16.4811 (Yes, the I in Intel is missing.) I am not having problems with Krita crashing. I apologize if I misunderstand Krita's autosave, but it doesn't appear to be working. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396095] Pixel Brush Rotation Does Not Respond to Pressure
https://bugs.kde.org/show_bug.cgi?id=396095 --- Comment #4 from Kenneth Evans --- Hi Dmitry Thanks for the info. I didn't know what Fuzzy Dab is. Nevertheless, the bug is that it doesn't respond to pressure. I do have 1024 levels of pressure. The preset is also set to Opacity on pressure, and you can see the opacity varies. In general pressure works fine for me in Krita. Your screenshot just shows you can set it (unless I missed something). Does it work? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396095] Pixel Brush Rotation Does Not Respond to Pressure
https://bugs.kde.org/show_bug.cgi?id=396095 --- Comment #1 from Kenneth Evans --- Created attachment 113719 --> https://bugs.kde.org/attachment.cgi?id=113719=edit Pine Needle Brush Preset Pine needle brush preset attached. Set rotation to Pressure to verify issue. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396095] New: Pixel Brush Rotation Does Not Respond to Pressure
https://bugs.kde.org/show_bug.cgi?id=396095 Bug ID: 396095 Summary: Pixel Brush Rotation Does Not Respond to Pressure Product: krita Version: 4.1.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Created attachment 113718 --> https://bugs.kde.org/attachment.cgi?id=113718=edit Krita Image Illustrating Problem I would like to make a brush for drawing pine needles. I would like the rotation of the pattern to be random, but that does not seem to be one of the options. The rotation does respond to Drawing Angle, which seems to be somewhat random, and that solves my problem, more or less. However, I should have been able to use Pressure, or perhaps somethings else (I am not completely sure what all the others are), perhaps with a wavy response curve. It does not seem to respond to pressure, and this seems to be a bug. Note this is on a Surface Book with Microsoft's NTrig pen, which does not report tilt nor rotation. I am attaching a Krita file PNG and the brush preset. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 395764] invert selection is missing from selection menu 4.1.0 beta.2
https://bugs.kde.org/show_bug.cgi?id=395764 --- Comment #5 from Kenneth Evans --- @Keith and Wisteria. Thanks, those should work. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 395764] invert selection is missing from selection menu 4.1.0 beta.2
https://bugs.kde.org/show_bug.cgi?id=395764 Kenneth Evans changed: What|Removed |Added CC||k...@kenevans.net --- Comment #2 from Kenneth Evans --- Missing in 4.1.0 too. This is kind of critical. How do you invert a selection apart from using the keyboard (which is not available when using my Surface Book folded up for drawing). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 395774] Doesn't prompt to save KRA before Saving as PNG
https://bugs.kde.org/show_bug.cgi?id=395774 --- Comment #5 from Kenneth Evans --- I tried export and that is probably what I should be using. I didn't realize that, and was using what I would in other programs. Thanks. I still think it should be fixed. Being warned about losing information is a completely different thing. (I never even noticed that warning. It's very small print on my computer.) Of course you lose information saving to PNG. That has nothing to do with unsaved changes The point is I am losing unsaved changes in the KRA file and am never prompted about that. That is a bad thing. I may have missed all the items you mentioned. After all, had I been careful, I would have saved anyway. I will not miss a prompt I have to respond to. The steps in the message above is what has happened to me. If I had been more alert I would have saved the KRA file anyway before saving the PNG and usually do. The prompt prevents oversights and mistakes. Note that you are leaving the KRA document and entering a completely different document as it is implemented. Unsaved changes are lost. What more can I say. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 395774] Doesn't prompt to save KRA before Saving as PNG
https://bugs.kde.org/show_bug.cgi?id=395774 --- Comment #2 from Kenneth Evans --- Thanks, I'll try export. However I think this should be fixed. Having a check box in a dialog is a long ways from prompting you for sure to not lose your work. It is almost universal to ask to save before leaving unsaved work (for good reason). Krita is not doing that in this case, and that makes it unfriendly. And it isn't that hard to fix. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 395774] New: Doesn't prompt to save KRA before Saving as PNG
https://bugs.kde.org/show_bug.cgi?id=395774 Bug ID: 395774 Summary: Doesn't prompt to save KRA before Saving as PNG Product: krita Version: 4.0.4 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Since it is going to close the KRA document or at least rename it to PNG, any unsaved changes to the KRA document are lost when you Save As | PNG (and probably others). This has caught me twice now. Actually I would prefer it not rename the document to PNG but continue working on the KRA, but this issue is just asking it to be fixed to prompt you to avoid losing work. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394067] Various issues with the current palette docker
https://bugs.kde.org/show_bug.cgi?id=394067 --- Comment #3 from Kenneth Evans --- There was some indication this was worked on in 4.0.4. It does seem to be better, but still flakey. In particular I notice: 1. Adding a color gives a narrow rectangle rather than a square one. 2. Selecting a color in the palette as often as not brings up the properties for the color instead of setting the color. I assume the latter is supposed to happen on a double click. 3. I have had good luck with an added color appearing (subject to item 1) but deleting a color often doesn't remove it from the palette as displayed. All of these can be fixed by selecting another palette then going back to the one I am using (a real nuisance to do). It thus seems as if the refresh that is being performed after actions like the above is not as full a refresh as is needed. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 395705] New: Editing Masks is Very Slow
https://bugs.kde.org/show_bug.cgi?id=395705 Bug ID: 395705 Summary: Editing Masks is Very Slow Product: krita Version: 4.0.4 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: major Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Editing a mask by drawing on it is very slow for me. I have experienced this mostly with Selection Masks. Even drawing a small stroke, it can take tens to hundreds of seconds to display the results. There is no indication that it is busy. Just nothing happens for a very very long delay. It seems to happen with a Transparency Mask, as well. It has been consistent (always slow in my experience), and happened with 4.0.3 as well as 4.0.4. For Selection Masks, the only thing that works for me is to make a Paint Layer with the mask on it mask on it, then use Select Opaque. Editing the Paint Layer is fast and responsive. Editing the mask after it has been made into a selection is very very slow. (This workaround doesn't work for Transparency Masks, which seem to be B, not transparency based, nor is a selection involved.) Also the workaround doesn't let you see the selection results in Mask Mode as you paint. I don't believe it is the computer. In general Krita is very responsive for me (except maybe when using very large brushes). The delay is only with masks. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394139] Color History and Common Patches Show on Wrong Display
https://bugs.kde.org/show_bug.cgi?id=394139 --- Comment #7 from Kenneth Evans --- I am running Krita on Display 2. I don't know what you have. That might be important. In addition, Display 2 is to the left of Display 1. What you would think is independent of the multiple screens is that if I detach the Advanced Color Selector (the only way I can use it as it is then fully onscreen), sometimes the current color block shows on the right but eventually moves to the left. (When it is on the left I can leave it docked and it works without going off screen.) Why is it appearing on the right on this computer and on the left on the Surface Book. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394581] Changing brush option changes the pattern also
https://bugs.kde.org/show_bug.cgi?id=394581 --- Comment #3 from Kenneth Evans <k...@kenevans.net> --- I'll try to be more more explicit: 1. Choose Wet Paint and open the options panel. 2. Look at Pattern under Texture. 3. Be sure the tag is set to Krita_4_Default_Resources. This makes a difference. It didn't happen when the filter was set to another tag. See below. 4. Set the brush to the default. 5. Look at Pattern under Texture. Nothing is selected. There is no name over the place where the pattern would show. If it has a flat pattern, there is no way to tell. 4. Uncheck size under General. (Focus goes to Size.) 5. Go back to the Pattern you looked at before. Now 02 rough canvas is selected and shows on the right. Yesterday I did this many times and the pattern was always changed. Today it is happening most of the time but not every time, so there is a lack of consistency. Having the filter set to something besides Krita_4_Default_Resources may or may not have been the cause one time. It has also worked "right" (not set a pattern) with the tag set to Krita_4_Default_Resources at least once this morning. I repeat that most of the time it sets the Pattern to 02 rough canvas (for me). To clarify: Size under General has Pressure selected. It isn't really relevant. Sorry. For this example I am only looking at two options: Size under General and Pattern under Texture. I do not check or uncheck Pattern, just look at it. The only change I make is to check and uncheck Size. In addition, I left it at Krita_4_Default_Resources when I closed Krita last night, and Pattern came up with a filter set to another tag today. This is probably unrelated to the issue at hand, but I mention it for completeness. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394581] New: Changing brush option changes the pattern also
https://bugs.kde.org/show_bug.cgi?id=394581 Bug ID: 394581 Summary: Changing brush option changes the pattern also Product: krita Version: 4.0.3 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Use Wet Paint as an example. It has Pressure checked as an option. If you click on Pressure you see no pattern selected. The icon to the right is either blank or solid (probably blank, I can't tell). Now uncheck Size and re-check it. Now the brush has a pattern. It didn't go back to the default. If you now go to Pattern, the first pattern is selected (02 rough canvas) and there is a pattern shown to to the right. This probably is true for all brushes with pattern checked by default. And it happens when changing other options than Size. There doesn't seem to be a way to deselect the pattern used (once it has decided to use one), except by unchecking Pattern. It is unclear why pattern is checked. But if it is checked, the pattern should be consistent when other parameters are changed. I expect most users don't want this brush to have a canvas texture. It only works "right" because there actually is _no_ pattern associated with it by default even though Pattern is checked. If the pattern stayed that way when checking or unchecking size, that would be ok, I guess. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394139] Color History and Common Patches Show on Wrong Display
https://bugs.kde.org/show_bug.cgi?id=394139 --- Comment #5 from Kenneth Evans <k...@kenevans.net> --- This problem is more serious than I thought. I have had trouble using the Advanced Color Selector. Part of the reason is that I don't see the color that I am selecting, making it hard to choose the right color. I am now seeing the reason is that it is also using the Color History mechanism, and the preview patch doesn't appear on my display (when the selector is docked in its default place on the right). If I float the Advanced Color Selector, then I see there is a patch with the color I have chosen, the previous color chosen, and the previous color used (I think). Even then, sometimes the patches appear on the left and sometimes on the right. When they appear on the right, which seems to be the usual case, then they are all or mostly off screen when the docker is docked. If I can get them to be on the left, then they often stay on the left when re-docked. This is the behavior I would like, because they are then visible. However, I don't know the steps to make this happen, and by default they are on the right and not visible. On my Surface Book, with only one display, the patches seem to appear on the left when docked on the right, and there is no such problem. Thus there appear to be several problems associated with having more than one display: 1. Color History (H) appears on the wrong display. 2. The patches may appear on the left or the right of the Advanced Color Picker, seemingly randomly. They need to be on the left if docked on the right, and on the right if docked on the left to be seen. (I only use it on the right myself.) The default seems to be to be on the right, possibly because my other display is to the right of the one I am using. As far as I can recall, all the other art programs I use (and there are several) have the currently chosen color and also the secondary color on the window with the color diagram where you click to choose the color; that is, not floating. At least then it is always visible without these problems. However, the way it is implemented you do get a larger color patch (if it just worked right). This is a serious problem because it interferes seriously with choosing a color when you can't see the color you have chosen. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394171] Text Sizes Are Too Large
https://bugs.kde.org/show_bug.cgi?id=394171 --- Comment #4 from Kenneth Evans <k...@kenevans.net> --- Thanks. I just downloaded it and see that. Cool. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394171] Text Sizes Are Too Large
https://bugs.kde.org/show_bug.cgi?id=394171 --- Comment #2 from Kenneth Evans <k...@kenevans.net> --- The DPI of the image is 300. At 1600 x 1200, that makes it 3" high, and the fonts are consistent with that. So now I understand how it works, and it isn't a bug. I thought when I made it that it was 16" x 12" @ 300 dpi, in which case I wouldn't have had this problem. I apparently got the wrong preset. I would still like a smaller font. Other programs let you enter a number for the font. But that would be a feature request. I have figured out in the meantime that I can use the SVG mode and set the size, which is a workaround. I apologize for the submission, and I appreciate your help. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394171] New: Text Sizes Are Too Large
https://bugs.kde.org/show_bug.cgi?id=394171 Bug ID: 394171 Summary: Text Sizes Are Too Large Product: krita Version: 4.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tool/Text Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Created attachment 112602 --> https://bugs.kde.org/attachment.cgi?id=112602=edit Screen Shot of Text Sizes in a 1600 x 1200 Document (Zoomed to Fit) The text tool font sizes are a fixed selection from 6 pt to 72 pt. Unfortunately for me even the smallest is very large. I will include a screen shot. Note that the smallest size (6 pt) is much larger than the font size in the UI, and certainly isn't 0.083 in (assuming 1 pt = 1/72 in). 6 pt is usually a very small font, but not here. The net result is that even using the smallest font size, the text is too big to look good. This may be owing to the fact my Display 1 is high-res @ 250 DPI. However, Krita is running on a Cintiq on Display 2 @ 96 DPI. Krita is set to "Override high DPI scaling behavior. Scaling set by System." This means Windows tells it the DPI is 96, which is correct for the Cintiq anyway. (Enable H-DPI support is unchecked because it doesn't give good results, probably owing to its not being PER_MONITOR_DPI_AWARE.) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394139] Color History and Common Patches Show on Wrong Display
https://bugs.kde.org/show_bug.cgi?id=394139 --- Comment #4 from Kenneth Evans <k...@kenevans.net> --- I checked the behavior on a single-monitor computer. Apparently it is supposed to come up at the cursor. It looks to me like it is doing that except that it has x wrong. Other windows in Krita come up where expected. The difference with this one: No borders Comes up at cursor, not fixed screen position. If you can't fix it (because it's in Qt?), it isn't that critical. I'm just reporting. I do use color history often in other applications, and it is more conveniently implemented in at least some of them. I'm just learning Krita, so perhaps it is my inexperience. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394139] Color History and Common Patches Show on Wrong Display
https://bugs.kde.org/show_bug.cgi?id=394139 --- Comment #3 from Kenneth Evans <k...@kenevans.net> --- Created attachment 112598 --> https://bugs.kde.org/attachment.cgi?id=112598=edit Dual Monitor Screen Shot of Color History and Common Patches Locations -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394139] Color History and Common Patches Show on Wrong Display
https://bugs.kde.org/show_bug.cgi?id=394139
--- Comment #1 from Kenneth Evans <k...@kenevans.net> ---
Sorry, the virtual screen is {X=-1920,Y=0,Width=5760,Height=2160}.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 394139] New: Color History and Common Patches Show on Wrong Display
https://bugs.kde.org/show_bug.cgi?id=394139
Bug ID: 394139
Summary: Color History and Common Patches Show on Wrong Display
Product: krita
Version: 4.0
Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Color Selectors
Assignee: krita-bugs-n...@kde.org
Reporter: k...@kenevans.net
Target Milestone: ---
My primary display is Display 1 and is 4K. I have a Cintiq (1080P) running
Krita on Display 2. Display 2 is to the left of Display 1. If I use the Color
History (H) or Common Patches (U), they show up on Display 1 at the left edge.
I can find no way to move them to Display 2.
It is a problem for me because Display 1 is not readily visible from in front
of the Cintiq Display 2.
They are always at or near the left edge of Display 1. Depending on where the
cursor in Krita is, they are slightly higher or lower.
Windows treats the screen as a large virtual screen (8640 x 3828).
Display Information
Monitors: 2
Virtual Screen: {X=-1920,Y=0,Width=5760,Height=2160}
Primary Monitor Size: {Width=3840, Height=2160}
Device Name: \\.\DISPLAY1 (Primary)
Bits per Pixel: 32
DPI: 240 (250%)
Bounds: {X=0,Y=0,Width=3840,Height=2160}
Working Area: {X=0,Y=0,Width=3840,Height=2060}
Device Name: \\.\DISPLAY2
Bits per Pixel: 32
DPI: 96 (100%)
Bounds: {X=-1920,Y=331,Width=1920,Height=1200}
Working Area: {X=-1920,Y=331,Width=1920,Height=1160}
It looks like these popups are displaying with the correct y but the wrong x.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 394131] New: Issues Creating / Editing Resource Bundles
https://bugs.kde.org/show_bug.cgi?id=394131 Bug ID: 394131 Summary: Issues Creating / Editing Resource Bundles Product: krita Version: 4.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Resource Management Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- I have the following two issues when creating or editing resource bundles: 1. In editing an already-created bundle, it shows the former icon. However on saving, it does not use it, and I get the red one instead. In order to keep the current icon, I have to search again for the file. In the first place it should use the current one (it knows what it is) unless I do something. In the second place, it is misleading to show the icon if it is not going to use it. 2. In either creating or editing, I select my Brush Preset and my Brushes. It however, does not use the brush I select in brushes. I _am_ using an existing brush, not one in AppData/Roaming/krita/brushes, but it should still let me use it. If for some reason Krita doesn't want me to use it, there should be a warning when I move it to the right. Silently not including something without letting me know is unfriendly. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 394067] New: Palette is really flakey
https://bugs.kde.org/show_bug.cgi?id=394067 Bug ID: 394067 Summary: Palette is really flakey Product: krita Version: 4.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Dockers Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- I am having trouble using the Palette docker at all. Some examples: I save a new palette, say Test, then select it, then press + to add a color: Nothing happens The added colors seem to appear if I choose another palette, then re-choose Test. Having some colors showing, I then press delete (Circle with slash): Nothing happens. Again, if I choose another palette, then re-choose Test, the color is not there. These two seem reproducible. At other times: Pressing delete: Krita crashes. Sometimes the added colors have appeared but in narrow boxes, not squares. Cannot drag the colors. Sometimes can drag the colors but only to the left. Creating a new Group fills it with ten colors of the last selected color. Can't delete groups. So far have been able to drag a color from one group to another. I haven't quantified all these. I also haven't redone all the tests I made with selecting another palette, then re-selecting Test after doing an operation. The fact that it doesn't refresh is undoubtedly compounding the problems. At a minimum, not refreshing is an issue. I have started and restarted Krita numerous times and cleaned out the bad palettes in AppData/Roaming/krita/Palettes. It has crashed maybe five times in the last couple of hours. I also notice Save does not save the current palette with a new name, but creates a new, empty one. I'm not sure if this is the correct behavior, but it is not what I would expect. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392499] The masked brush opacity and flow options are confusing for some users
https://bugs.kde.org/show_bug.cgi?id=392499 --- Comment #5 from Kenneth Evans <k...@kenevans.net> --- > I don't think your first issue has anything to do with any DPI scaling at all. I agree. However, the icons are way too small. This happens often on high-res displays when high DPI is not implemented right. That is the only reason I mentioned it. Running in the mode I described on a 96 dpi display _should_ show no problems, and I don't have any other DPI issues with Krita 4 on this machine. I also plan to use it on a Surface Book with a high-res display. I haven't installed Krita 4 there yet, but I did not have problems with Krita 3.3.3. So for right now, I probably won't do anything about high DPI. It wasn't my intention to make this a DPI issue. Krita's built-in high DPI option doesn't work so well for me, but that's not a problem (for me). > Am I understanding it correctly? Yes. What you said is what is happening. The problem is compounded by the small icons. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392499] The masked brush opacity and flow options are confusing for some users
https://bugs.kde.org/show_bug.cgi?id=392499 --- Comment #3 from Kenneth Evans <k...@kenevans.net> --- I didn't see it as two issues. The tiny icons, whatever the cause, contribute to the confusion in seeing the hierarchy. However, I appreciate your looking at it and understanding the problem(s). Please handle it however works for you. Thanks again. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392499] New: Misleading Brush Properties Dialog on Windows
https://bugs.kde.org/show_bug.cgi?id=392499 Bug ID: 392499 Summary: Misleading Brush Properties Dialog on Windows Product: krita Version: 4.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: k...@kenevans.net Target Milestone: --- Created attachment 111725 --> https://bugs.kde.org/attachment.cgi?id=111725=edit Screen shot of brush properties dialog. The list of options in the Brush properties dialog is very hard to use. The icons to open or collapse the collapsible options are too small to tell what they are, and the check box doesn't show unless it is checked. Image attached. The layout completely hides the structure of the options. For example, there appear to be two Flow and Opacity options. It is not at all clear (to a new Krita user like me) that one is under General and one is under Masked Brush. Even though I have now figured out what it happening, I find it inconvenient and difficult to use owing to the misleading indentation. This is on Windows 10 64-bit. In the Properties for the shortcut Krita is set to use Compatibility | "Override the high DPI scaling behavior. Scaling performed by System." (The built-in DPI scaling is not usable.) This makes it be a 96 dpi program, which on my case is running on a 96 dpi Cintiq. This should make it work the same as if it were run a system with a normal resolution (96 dpi) monitor, so I don't know why the icons are so small. The reason the built-in scaling doesn't work is probably because the main display is 4K and the Krita scaling is not per-monitor aware. In any event, it is very unintuitive with the indentation as it is. -- You are receiving this mail because: You are watching all bug changes.
