Registered Member
|
I was thinking about tackling this project and have Krita remember A LOT more settings when you reboot it. Right now Krita doesn't remember too much if you play with settings at all. I got one tool loading/saving settings (crop tool) on my machine, so I think I have enough confidence to do it more globally.
Is there any settings we *don't* want to remember? The only things I thought that would might get annoying is if we saved visual things like if the mirror tool was on - or if the grid was on. Starting up a new file and seeing a busy grid might not be good. Or maybe it would be a cool thing for it to remember every setting you clicked. Whenever you come back, it will resume exactly how you left off. What about if Krita would remember the last settings you used for the crop tool (width, height, x position, y position)? Is that type of memory too much? It is interesting to think of where the line is of settings being useful vs. cluttered. Thoughts? |
KDE Developer
|
I think there are different kinds of settings: grids, mirror, (maybe) rotation could be saved in the .kra file; tool options like the current stabilizer mode should probably be global, I guess the initial size of the crop rect should not be saved, but be image or, if present, selection -- though whether the crop tool acts on layers or image might be saved as a setting. What I hate about photoshop is that it saves the last used color and tool, I think it would be preferable for Krita to always start with the freehand painting tool. The color history probably should be saved with the image.
|
Registered Member
|
Looking through the kritarc file, it looks like quite a few things are saved already. Preferences are saved, window states, as well as a lot of the color options.
Maybe even just saving more of the tool settings would be a good first step. Some areas are going to be difficult to judge how useful saving settings are. I don't think most people expect a lot of properties to be remembered (like filter settings, levels, HSV) I originally was wanting to modify the crop tool settings, so I think at least tool settings would be beneficial since those are frequently used. |
Registered Member
|
As I am going through the code of a couple of tools, I am noticing some inconsistencies with the implementation. I have looked at the crop tool and text tool so far. Do these tools use a good pattern for how they are organized/setup? These two use cc files for the logic, and and a widget that stores the UI.
Maybe I can do some code cleanup as well as I am adding in some of these settings. |
KDE Developer
|
Inconsistencies are likely due to the text-tool being a Karbon tool(partially, only artistic text is Krita), and the crop tool is mainly Krita. As Karbon is unmaintained, Krita is going to look into better native vector support for the 3.x series. The text-tool will get bigger scrutiny(if not a full rewrite) then. As far as I know, all tools have a widget-part and a functionality part, and some have a helper part(which handles inbetween operations, such as the free-hand tool's smoothing options). I wouldn't worry about it too much, but if you want, you can make a list and we can discuss whether or not it's really necessary. Also, Scott, maybe consider using the development forum? My inner organiser is being driven batty by you posting these in general. |
Registered Member
|
thanks for the feedback. I can post this in the developer forum with technical things.
The original question was geared more publicly to see if anyone had a strong preference. It wasn't originally intended to get programming specific. I probably should have made a new thread in the developer area once I started interjecting code stuff. |
KDE Developer
|
You can also ask a moderator to move the topic for you. I think it's better to keep a discussion together, otherwise people will have to do detective work to figure out why a certain decision was taken. Overall, there's no no-users-allowed area on the forum, so don't worry about that. Hell, even in IRC and Mailinglists there's no no-users-allowed, though sometimes discussion can get very abstract due programmer talk. |
Registered Member
|
I've always wanted the Dynamic Brush to remember its settings. I prefer using it over the Freehand Brush, as it gives smoother, more controllable line work when set to Mass: 0.01 and Drag: 0.98 (from what I'm told those settings give different results on Linux though). Presently I have to adjust those settings every time I load Krita up, which is a bit of a hassle.
|
Registered Member
|
@Chris Jones
You sound like you use that tool quite a bit! I can make those values the default as well the first time the tool is loaded. It doesn't sound like the current default is the 'best' place to start for new users. I personally haven't used the dyna brush very much. The default settings always felt a little awkward, so I ended up avoiding the tool entirely. It is pretty nice with the values you recommended. That does bring up a good point about values. I originally wasn't sure about saving number values like that, but it might be a good idea. |
KDE Developer
|
Right now I wouldn't spend a lot of time on cleaning up inconsistent coding styles. That might make merging branches more difficult. After the 2.9 release, we'll have a period for cleanup in order to prepare for a nice and orderly porting to Qt5.
|
Registered Member
|
ok. I think I have just about all of the various tool settings saving now and pushed to master. There are a couple of tools where the properties are dynamically generated, so I can't figure out how to do those (bezier curve tool and freehand path tool). The only settings that are saved with those are the fill and outline types since those are set on a parent class. What I have is probably good for now.
|
KDE Developer
|
Very, very nice! See also: https://krita.org/item/new-development-builds-2/
|
Registered Member
|
Splendid! Thanks Scott (and Boud (and team)).
|
Registered users: abc72656, Bing [Bot], Google [Bot], lockheed, Sogou [Bot], Yahoo [Bot]