Sure.

Shall we close this?

Possibly a stop watch symbol??
I'm not good at drawing but good at photo shop.

In T3496#163171, @scottpetrovic wrote:

Here is an idea I had about how the UI and UX would work with animation cycles. Not sure what people thought.

Here is an idea I had about how the UI and UX would work with animation cycles. Not sure what people thought.

My main concern for the cycles is making sure these controls don't start overlapping. If we start overlapping any existing items, this could be difficult to use fast. We will only be able to change and move things from a right-click menu since there selecting it on the timeline will be difficult (are we selecting the frame contents or cycle?). So far the two versions of the mockups I have seen have overlapping UI elements between the frame and the cycle which is going to make manipulating more difficult.

• User can select a (continuous) range on the timeline, open the context menu and select "Create cycle".

I assume in your example the run cycle is drawn somewhere outside the range of frames you describe here.

In T3496#143273, @emmetoneill wrote:

Sounds good. Does "draw on repeats" mean that if you drawn on a "ghost" of a frame it will also modify the original frame and all other ghosts? That sounds convenient, if I'm understanding it right.

Our users should be able to:

• mark a cycle on the timeline
• change the range frames which are repeated
• edit the frames of a cycle. Changes should be reflected in the repeats.
• convert repeats into actual keyframes or clone frames
• draw on repeats without breaking the cycle due to automatic keyframing (option in autokey?)

Thanks for the mockup, Emmet. Based on it, we continued discussing the feature with Bollebib today. We gathered some requirements and possible solutions.

Hey everyone, I just wanted to share a possible design mock-up for animation cycles that I put together.

In T5882#95638, @woltherav wrote:

KisBaseNode has a keyframes() which does not give access to a QMap, but rather the QList of of a QMap.values(). This is not too bad, as the QMap.keys() contain standard IDs noted in KisKeyFrameChannel.

Outch... Generating a list of the values in a map is _expensive_. That really needs to be refactored in KisBVaseNode.

KisBaseNode has a keyframes() which does not give access to a QMap, but rather the QList of of a QMap.values(). This is not too bad, as the QMap.keys() contain standard IDs noted in KisKeyFrameChannel.

Plugin to add a docker that shows most recent opened documents with thumbnails - same as the other docker idea?

When developing games, they often need to combine multiple grayscale "channels" (hightmaps, textures, lighting) into one RGBA image to pass to the game engine. This combining is very custom and it is an ideal target for being implemented as a script. And it is also a nice target for showing raw data access.

I suspect that you haven't built Krita with scripting yet? This is already implemented, and managing the scripts is part of the settings dialog.

I would argue having one or two regular operations scripts(such as web export) would be good because then we can verify whether this is possible with the current API. Similarly, people use these scripts as a basis for their own.

In T5885#94481, @dkazakov wrote:

Hi, @eliakinalmeida!

I'll try to lay out my ideas about scripting here:

1. As far as I can tell, the main purpose of the interactive scripting editor and the showcases is to allow the user to extend his Krita with some custom functions that save his time. It means that we should pay attention not only to the script editing part, but also to way how to run them. So at least such features might be necessary for the user:
   1. A docker with a list of "registered" scripts that allows the user (can be implemented in python as par to the showcase actually):
      • add/remove "registered" scripts
      • run/stop script
      • group scripts in folders
      • assign a shortcut to the script

Yes, I think that the Frame object should have a pixeldata method just like the Node object.

I'll try to lay out my ideas about scripting here:

• Image color space for multiple documents - yes, that should be an easy one
• Changing canvas size for multiple documents - same thing, doesn't need new api either
• Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list). - yes
• High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972 - yes
• Docker that shows thumbnails for last ten opened images - yes
• A multifill script - http://davidrevoy.com/article306/tons-of-potions-part-2-multifill - yes
• Export all the layers (batch) - http://registry.gimp.org/node/28268 - yes
• An "export to web" script - doubtful...
• Duplicate image. Could be interesting
• Scale down an image. - same as the second one?
• Export to jpg X% quality. - doable, a bit trivial
• Plugin to add a docker that shows most recent opened documents with thumbnails - same as the other docker idea?

i second what woltherav said.

As I told to Boud, I'm talking with users to get some interesting ideas and suggestions to these next three months implementing Krita's showcase to for the GSoC.

Yes I agree with a lot of @Bollebib points. If we are doing a "cycle", we need to have some concept of a set of frames to be repeated. Right now everything is just one frame at a time. With adding the idea of cycles, there might be a lot of work needed behind the scenes to support that concept like empty frames and a different display for a group of frames.

there might be some discussion needed still,you can often find me on IRC for an animator's input.
The following will be my initial thoughts but can be downscaled to make it more manageable or expanded to make it more feature complete. I have no idea how big this project needs to be for the student,so it will need discussion.

I think it would be good to see how this fits in to the big picture when we do the UI. Here are the mockups for the original discussion. https://phabricator.kde.org/M2

One of the students chose the task for his practice task. Please add your ideas about what you think should be implemented here! :)

Hm... wouldn't it be necessary as well to make sure that people can access the resultant pixeldata of a given frame? especially when dealing with opacity keyframes. Like say, if someone wishes to make an exporter that generates a spritesheet, they would want to take a node and itterate over the frames, but not touch the actual keyframes.

I would suggest having an object to represent a keyframe, as there are a fair number of properties they have. Specifically, all keyframes have time and color label. Opacity frames have their value, interpolation modes and tangents. Raster frames of course have pixel data.

I'm agreed with @stamoglouodysseas. We need a checkbox in preferences not to draw behind the canvas. I guess it's easy to add.
With this checkbox everyone will be happy.

@woltherav
At the moment you cannot see what you do beyond the canvas boundaries, so it wouldn't really serve that purpose. It would make sense if we had a bleed area like layout software (coreldraw,illustrator, etc), where you can actually see the whole image. But perhaps this goes a bit too far..

Bleeding space would fit into artist's workflow, as it is how people use the same concept in printing. We just need to allow a 'export with bleeding space' type of option somewhere and it would fit right into a print workflow.

These options could help, although in practice it is almost the same effort as trimming the layer to image size or manually cropping the image. You require the user to take an extra action to trim the layers to image size.
I personally do not have any use for the strokes beyond image boundaries, and would like to have a default setting that prevents it from happening.
I understand that others might have use for it though, so this is where the bleeding space idea came from.

I'm also fine with not writing pixels when painting outside the canvas area -- that way, strokes can still start outside the canvas, but it won't grow the image.