scottpetrovic wrote:I am going through the "new developer experience" right now and have some questions that might make help new Krita developers get started.

scottpetrovic wrote:1. What IDE do you guys usually use? It looks like there are a few options in the build settings?
- whatever you chose, why that one?

scottpetrovic wrote:2. What is your workflow like. Do you usually go to the bugs.kde.org, find something, do some research, then make the fix.

I usually have different things going on. They can be divided into categories, though:

• Features and refactorings. Sometimes you just know that a lot of work is going to be needed to reach a particular goal and also that the goal is desirable. This I mostly do in separate feature branches, because I might have two or three of these projects going on, though Dmitry, for instance, does his feature work in one testing branch, which makes it easier for users to check his progress.
• Performance improvements. Sometimes I don't feel like working on a feature, or someone mentioned something being particularly slow. The first thing to do then is carry out that scenario when Krita runs under callgrind and vtune -- those tools show bottlenecks at the end of a run. It's important to use both, since both give different insights!
• Bugs. Sometimes ones rummages around the bugs on b.k.o to see what looks likely to make a nice Saturday morning fix, sometimes a bug is really urgent (like all data loss bugs), sometimes someone on irc or the forum mentions a bug... To fix a bug, the first thing is to reproduce it, the second thing is to look in the code what might be going on. But if it's a crash bug, especially one that seems mysterious, it might help to google for a few of the key lines in the backtrace -- sometimes it's a distribution issue!
• Featurettes. Especially people who have joined the development fund or who have contributed hugely to Krita by working on icons, testing branches, developing websites... If they mention on irc that something impedes their workflow, or that they have a deadline and maybe need a quick plugin to meet that deadline, well, then I drop everything and try to implement what they need, then and there. If it's feasible!

scottpetrovic wrote:3. How do you debug and test. Any extra tools that make things go faster?

Here it's like this: there are big and small problems. For small problems, the debugger in Qt Creator (run external application) or adding qDebug messages to the code is fine. But if the problem is difficult, the first step should always be to write a unittest. A small bit of code that follows a set pattern and exercises the faulty code and shows the problem. That helps so much figuring out a fix and _keeping_ it fixed. It's not like we're really good at keeping unittests 'green' -- that is make sure all run without problems, but it's still an important too

scottpetrovic wrote:4. Is there any documentation on the code architecture. I don't see a whole lot of comments in the code, so it is hard to know where things are without stepping through everything.

Hardly... We've created a number of things, ranging from a presentation for gsoc students to a developers handbook over the years, but krita develops so quickly that all those efforts are outdated before we mnage to finish them!

scottpetrovic wrote:5. If this is using Qt, would websites like this be of any value for learning Krita? http://qt-project.org/doc/qt-4.8/how-to-learn-qt.html

Yes. Also get C++ in a Nutshell by O'Reilly and I usually give Summer of Code students a copy of the Design Patterns book. The most important step someone coming from java/c#/scripting needs to set is to really understand memory management: pointers, smart pointers and pointer arithmetic. For an application like Krita, it's essential.

scottpetrovic wrote:I saw a video by Campbell Barton at Blender a while back with a quick demo of his worfklow. Judging by the comments, this type of thing is very useful.