Natron UI Project


Jean-Christophe proposed me to work on the color picker, I thought you knew. He said he was going to send me more specifics later so in the mean time I am experimenting on my own.


I just got the specifics from Jean-Christophe, it looks really neat. If he does not post the mock-ups here I will post them soon, so that everyone can enjoy them. :wink:


It is always nice to hear that a truly experienced developer working on a product you’re interested in. Keep up great work, guys.


Here are the mock-ups that Jean-Christophe made for the Color Selector. I started to implement it, you can find the code here with a couple of images of what the implemented version looks like currently.

Everyone is welcome to help or give feedback :wink:

Enjoy !


Well, looks legit. I can only hope that these little ugly circles will never made it into final implementation


I LIKE SO MUCH THIS COLOR SELECTOR!!! >>>>>“NatronColorSelector”<<<<< :scream: :grinning: :heart_eyes:

i’m greet for “stand out” for TRUE IDENTITY and NOT CLONE-NUKE because nuke is commercial…

@Azerupi you can try code in natron for testing…?

then you mock-up is TRUE GOOD and IDENTITY NATRON…here

need care color: white: default, blue:selected or actived, gray: inactived or unselected, red:keyframe inserted.

i dont know if will be new UI totally? because there is problem from QT4 style…

see example in future: QT5 new for fusion

other show for dialog colorwheel, you can go to see my screen record (link mega):!a5UkSYBK!nuDo7YZ3igkU_pm7vqINlUznDIYG5Ob52TO55A_M5RY


Looks good - RGB on same panel as HSV is good. Numeric control field should work like existing numeric fields in Natron in that the arrow keys can be used to move between decimal places and to control the value. It should be possible to have multiple colour pickers open at the same time.


I would like to challenge whether the standard Natron effects Left Toolbar serves any useful purpose?


You can hide it from the “Manage layout for this pane” menu anyway


Loving the mockups. Very impressive piece of software. The color picker is very sweet looking. The only critical comment I can make is maybe change the colors of the connectors on the nodes. I would try having the shapes blend in with the node color itself.


I see what you mean, and perhaps that is a general principle: if a feature can be disabled, then it is hardly worth contemplating to remove it entirely. Obviously I am ‘splitting hairs’ - that’s because I am taking a close look at the UI and not finding really anything that can be improved.


what i like is to leave left hand on the keyboard (right hand on mouse or keyboard) and therefore i have set my play-shortcuts as followed:


A - goto previous (whatever)
S D F - like JKL functinality (play forward, stop, play backward, multiple speeds from slow motion to very fast, and also move precise frame by frame)
G - goto next

for play arround (circle) it could work to activate it by A + D + F at the same time or by starting to press D (stop) first.

*(be careful i am not into compositing but film editing)


what about having two independent decks for the purpose of comparison two images or also to have two different kind of views on the same?

more of this concept here in my lumiera gui draft pdf


is it possible to think it as a type search query like the new mac os spotlight search to fire it up and bring the wanted controls in fast and flexible?


lots of creative people prefer to use the left hand / right side of the brain for taks like mouse catching! :wink:

well – es long as it’s configurable this doesn’t matter so much.

but i get confused by typical compositing applications, that tend to use ‘space bar’ for ‘full screen’ instead of ‘play/stop’, just the same.

[quote=“christophvarga, post:32, topic:330”]
what about having two independent decks for the purpose of comparison two images or also to have two different kind of views on the same?[/quote]

you can use wipes in every viewer to compare two inputs (A vs. B) or you can use serveral viewers/scopes…
that’s already possible.

but the relation to editing tasks is a very interesting [albeit rather complex] question (see:

just type ‘tab’ in the node editor and you get it! :slight_smile:


Timeline without a viewer

  • Do you ever want a timeline without a viewer?
  • Do you sometimes want just one timeline for multiple viewers?

The more you separate things, the less integrated they are of course. The more general purpose, the less it can be specialised to a specific task. Natron already has the intrinsic challenge of having three main regions (viewers, node graph, properties) and this would make it four. I can see the drawbacks of a separate timeline but not the benefits. What are they?


A single user interface is what Blender offers in its compositing node view: you get the viewer as the background to the nodes, and the node graph is floating on top. When we consider that there will be a major new kind of cinema in future - immersive (virtual reality) - it’s easy to see that UI paradigm working well there.

That said, Natron’s 3 region UI has already been built (so rapidly it’s impressive!). It is actually quite mature, for example, shortcuts that can be global are, which relieves some of the moving back and forth between panes/regions.

I think it is very healthy to challenge the design that you obtained through the ‘follow the headlights’ principle but please treat it as an experiment rather than committing, until significant users have put in the hours needed to evaluate the new concept to different use cases. You also have to be prepared to find that you have just confirmed that the existing design is best. The main goal should be for the chief designer to feel an ownership of the design.

It will certainly be easier now with few users than later, when you will have trouble distinguishing the user who is making a valid point from the user who is just resisting change.

Regarding how appealing Natron looks to a first time user, well the clunky old windowing toolkit is the biggest problem. Because it makes people question quality. Windows actually jumps around (you can see this better on an old low power computer).

Natron is like a galloping stallion - no need to slow down but keep it on a tight rein until you are sure you are really in control.


Thanks for the feedback!

I guess, when you have keyframed a property or added an expression to some node property you may want to change the current frame to see how the value changes.

Currently, every viewer has it’s own timeline. But all the timelines are synced together (correct me if I am wrong), so if you change one, all the others change with it. In that case, I don’t see much benefit in having multiple timelines taking up screen estate. And this is the reason I proposed this change in the first place.

  • When having multiple viewers, there is a win in screen estate, no need to have 2-3 timelines with their own playback buttons.
  • You can have a full screen viewer on a second screen without the timeline (timeline on first screen)
  • Timeline size is not dependent on viewer size (some prefer to have larger timelines ranging across the whole screen, but don’t want the viewer to take that much space)

There are probably other benefits (and drawbacks) I didn’t think off. Splitting the timeline does indeed add a little bit of complexity to the interface.


the behavior of natron does not follow nuke in this respect. if you press the little ‘lock’ in the timeline of the viewer, i does not sync with other viewers anymore in nuke. in natron the same lock-icon has a different semantic.

i would prefer to see it working as similar as possible to nuke, to make it easier for people to use this software and recycle the existing documentations and all the free add ons written for nuke and nukepedia.

but if you see serious arguments for necessary changes and deviances, we should listen and discuss their benefits.

i think, viewer nodes in open-fx pipeline can be seen as leaf-nodes that trigger the flow of processing through all nodes beyond them. that’s why they somehow dictate the position on the timeline of this actual output, but they are not setting a global context of synchronization. it makes some sense to me, to reflect this technical foundations of open-fx processing also in the GUI to some extent. but i may be wrong in this interpretation.


Thanks Azerupi, I am happy to be able to contribute to this analysis. So, I think we are all agreeing that these timelines feel like clutter. So we have a requirement:
Requirement 1: By default only show one timeline
(Workaround: bind ‘hide player controls’ and ‘hide timeline’ to keyboard shortcuts)

But as mash_graz pointed out we might sometimes need to stay on one frame in one viewer, while scrubbing in another. That functionality is not in Natron today. However, that can still be done even with a single timeline, by having it switch context to whatever viewer is selected. So I want to propose a second requirement:
Requirement 2: Ability to, in future, make separate playback of viewers
And a use case is needed for this. Maybe these:
2a In the middle of a roto, you want to check something in another frame. What is the easiest way?
2b You are deciding where to offset a clip. What is the easiest way?
They are just guesses - maybe an experienced compositor should say what the use cases are - I do not have the experience.

I look at Blender which has a UI that I love but I feel they did the wrong thing by keeping their views too general purpose. So I would not like to end up with one like that. What is especially awkward is having the timeline between the viewer and node graph, as just a standard overlapping window, so that you cannot just drag the border down, to make the viewer take some space from the node graph. So we need a requirement about that, and I am not sure how to state that requirement. [ EDIT: Got it:
Requirement 4: Timeline should be present no matter what the window layout is (but also hideable via shortcut).]

One easy one is, I hope all agree:
Requirement 3: Keyboard shortcuts for timeline should work globally.
And they do now.


i do not second all your conclusions.

why should we change something that brings more disadvantages than benefit?

in the most usual case, you have only one viewer and its including timeline on the screen. if you would put the timeline into an extra panel it will take more space, not less(!), because this extra panel needs additional decorations…
and if you have more viewers on the screen and you want to hide the controls on them, it’s very easy to do. all the necessary functionality already exits – just use the context menu.

so, why should we break this well working behavior?

no, that’s not the case now!

the ‘L’ key is usually bound to something else outside of the viewer! :frowning:
this kind of changing key code semantics in dependency of the actual focus does not look very nice, but users of compositing solutions and other similar complex software with lots of shortcuts get used to it. :wink:

but what i definitely do not like, is the binding of “O” for ‘toggle overlay’ in the viewer. :frowning:
it’s not, because “Q” (like in nuke) would look so much nicer, but “I” and “O” are very common options to set the ‘in’ and ‘Out’-point at the actual position on many other viewers of video processing applications. that’s so common, that nobody does expect something else.

but i general would not overestimate the need of more global control because:

a.) if several viewers are ganged by the ‘lock’ icon, it does not matter which one of them has the focus, your key press will lead to the same result.
and for contrary case:
b.) they are not connected, than it is necessary to control them individually by their own keys and control elements.

but that’s all quite close to the present behavior…