- User Since
- Apr 15 2015, 1:01 PM (200 w, 6 d)
Wed, Feb 6
Tue, Feb 5
I think I updated all your points. I ended up refactoring the code so it is shared. Adding more if statements for the pixel grid was a bit sloppy for me, so I moved it all to a new calculation function that does that for the other areas to use later.
Fri, Jan 25
@dkazakov I think most of the issues are resolved except the disputable one.
Mon, Jan 21
I updated the logic so it tries to more intelligently calculate the width and height when you toggle the vertical and horizontal. I think this should fix the issue @dkazakov found.
Sun, Jan 20
Jan 19 2019
Pushed and closing...
Jan 18 2019
@woltherav @amedonosova I could be mistaken, but this is just adding another way to get to the arrange functions. The Arrange docker is not being removed, so people can still go to that to use that if they want icons and a GUI interface for doing the arrange operations. I don't see really any reason to have a conflict of interest with this. There are a lot of things in the application that have multiple ways to access them. People like options.
Jan 17 2019
Jan 10 2019
Jan 9 2019
Updated the diff removing the extra logic and replacing it with a safe assert. Using the python, it seems ok and I don't get any errors or issues
Jan 8 2019
Jan 7 2019
forgot to close this.
closing this. I am not really working on it and it probably needs more discussion
Dec 19 2018
@emmetoneill I am not sure what you are proposing exactly. Are you proposing that we remove the reference guide, general concepts, and tutorials area. Or are you proposing to move all that stuff into the user manual under a beginner, intermediate, and advanced areas. The way I am reading your comment, the "big picture" appears to only talk about the user manual. I don't see any references to our other areas like tutorials, reference manual, or general concepts areas and how those fit in.
Dec 11 2018
@woltherav - alright, so you are thinking the user manual needs to do a couple things. Looking at a few pages, I see a pattern we might want to try to follow for all the areas in the user manual.
Closing this ticket. I am not working on this and I am not sure if there is a good way to get this data for krita.org to consume and show to people. We can look at it again if this comes up.
Nov 17 2018
Nov 15 2018
ahh. Looks nice!
Nov 14 2018
That looks great to me
Nov 11 2018
Great job anna!
Nov 2 2018
Nov 1 2018
To start off some discussion, here are a few questions I have with how this new site will fit in with everything else that we do...
Oct 29 2018
Thanks for the review @rempt
I changed all the checks to return the document instead of the active view.
Oct 27 2018
Oct 23 2018
Thanks for the video. I think some other artists that might use this are going to need to speak up about how this will work. This whole idea seems a bit confusing to me that changing your colors in the toolbar doesn't actually change the colors. If this is exactly what the artists want, we can roll with it.
Oct 21 2018
@rempt thanks for the reviews and help. Pushed out and closing this ticket.
I updated the updater logic a bit so it checks for two things, the active view and the file batch mode. My normal script still seems to work.
I updated the revision and added a couple null checks at the beginning for main window and the active view.
Oct 20 2018
I moved the function to the Document class and revised it a bit after talking with @rempt The one thing I wasn't sure with what to do was with the updater. It sounded like that could be extracted or removed somehow. I wasn't sure if that meant it needs a separate API call, or how that needs to be managed.
I guess I am a bit confused with how this will work. Will this only temporarily replace the foreground color and background color, or will this lock the foreground color and background color so the other color pickers won't do anything?
I am not sure about the code, but using the foreground and background color selector might not be the beste widget to use for this. Only one color needs to be selected. This widget is too complex for what needs to be done. I would use a more simple color picker....
Oct 17 2018
Oct 15 2018
Oct 14 2018
@amedonosova I think your personal preference would be find if saving to KRA by default. I have noticed in general people like everything to be saved, so they can open a document and it resumes the exact state it was before. I think if there is an option to manually disable, that would be ok if someone really wants to disable it.
Oct 13 2018
Is there a situation when someone specifically doesn't want this information saved to the KRA document?
Oct 12 2018
I haven't tested out the patch but I think the UI is fine. If we get more controls on it we might want to think about the UI more. For now this seems fine.
Oct 7 2018
Here is an idea I had about how the UI and UX would work with animation cycles. Not sure what people thought.
@dkazakov - ahh thanks for the clarification. The hard part with this widget is everything is inside a QStackedWidget. The way that works, the vertical height is determined based off the largest setting area. The largest setting area I found across all settings is the "auto brush masked brush tip". That has an extra options for blending mode which is how it gets that final height.
@dkazakov - for clarification, can you say what pixel dimensions that screen size is in for your screen shot? Everything is fitting in your screenshot, so I am not sure what you mean. I did think quite a bit about a situation with smaller screens. For people that want to use this that have very small screen, you can adjust or hide the brush stroke preview from the configuration options. That will shrink the height of the brush editor and make it take up less space.
This seems like it works perfect for me. I am approving it on my end.
Oct 6 2018
Oct 5 2018
Oct 4 2018
@radianart - in terms of organizing the setting areas, we probably need to do a bit more work and brainstorming. There are a few settings areas where you only select one option. For example painting mode and blending mode. I don't know if we need an entire settings area just to select one option. There are probably other tweaks like you mentioned as well with moving things around. Maybe a later patch could be trying to organize the settings a bit better
Oct 3 2018
I just pushed it out to master. If there are issues with it, it is all in one patch -- so it would be easy to revert.
I think the live text editing needs a bit more thinking and work, so I am completely removing that code from this patch.
Oct 2 2018
I submitted a patch with these set of changes that appear on the wireframe. This patch doesn't allow a detachable editor, but it condenses many of the settings to make it easier when we move this editor to a separate docker. It takes up a lot less space now than it did previously
@rempt - do different OSs have different export dialogs? I am on a Windows build right now and my export dialog does not have a "also save as KRA" option.
Oct 1 2018
@emmetoneill - good points.
I have most of this functionality implemented in my branch to look like the wireframes.
I think what you have is great!
Sep 30 2018
Sep 29 2018
Sep 28 2018
A couple comments on Youtube really like the idea of this being in a window. I am starting to think that it is more important to have this editor as a window/docker than a temporary popup like we have now. I think most other art programs have it as some type of window/docker as the only option.
@rempt - the idea with the scrollable area for settings is that if we turn this into a window/docker, people can resize it to be whatever they want. If they want to see everything, they can just resize it to be large. If they just want to see a small portion of it so it doesn't hog up so much of the screen, they can do that too. That was the idea.
Sep 27 2018
Here is some video progress with what I have been tinkering with so far. The video explains some of my thought process and how I am trying to think of different people and what they need from this editor.