Natron UI Project


#18

Overall it’s nice to see, that comunity is into making Natron better. Considering that right now developers team have much more important tasks to accomplish, i think that it is reasonable to make small, relatively easy to implement GUI improvements, such as desent color picker for example. Throwing my 5 cent into it, i came up with design sketches of little viewer widget that would be nice to have into Natron. This is overlay element that gathers parameters exposed by user in one semitrasparent movable panel in a viewer. It can be very handy when you fine tune your compose in fullscreen mode and sets you free from constantly scrolling through dozens of parameters of different nodes in property panel.


#19

I am working on that, but it’s going slowly as I haven’t coded in c++ with Qt for years. If you have any suggestions or you can show me reference images of a really good color picker in your opinion, that would be immensely useful. At the moment I was planning to begin with a HSL and HSV version.

Thanks for your input! This could indeed be useful when you don’t have a second screen. I am not sure though about what you mean by “exposed by user”. Do you mean that the user would have to explicitly right-click in the node properties and “expose control in viewer” for example? Would make sense to see as to have only the relevant controls at hand.


#20

You should not start coding on your own aside before proposing any idea. Jean-Christophe Levet, the man responsible for UI choices will be in the end our person we turn to, to make up our opinion before coding something.
He is actively working on UI propositions and so far he has worked on the following:

  • unified “workshop” interface (same panel for nodegraph/curveditor/dopesheet/timeline)
  • the color dialog will be a dockable panel (same as the node graph) that will be invoked when clicking the color-wheel of a parameter and then hidden when done
  • the file dialog will also be embedded as such a dockable panel
  • there are plans to make the UI more dynamic when selecting a node (displaying available layers in the viewers, temporarily open-up the settings panel and then close it when selection is gone etc…)
  • the node graph will have an auto-placement for nodes that will be much more intuitive
  • properties panels will be much cleaner

I will ask him to post his sketches here so that everyone is on page.
Please note that we are not going to make a brand new interface that nobody is going to understand, keeping close to what the industry standard uses (i.e Nuke atm) is for us the only viable option. That means shortcuts, layout, behaviour and tool names should be consistent.

The only part where we can operate is by making things more beautiful or less clunky to use (e.g color picker) and overall more enjoyable for the user.

Stylesheet is not a big concern (a part from the Combobox), rather people should focus on UI improvements that lower the number of mouse interaction required.

Note that regarding the UI, currently the only needed change to make Natron “stable” is to re-write the NodeGraph to use a raw QWidget backend instead of the QGraphicsView which is full of bugs (besides being freakishly slow)

I’m not trying to prevent you guys from spawning new ideas, but keep in mind that radical changes are NEVER appreciated by end-users.
We will pick up ideas here and there, but every change should be as small as possible so that people hardly notice it, or just raise an eyebrow mentally thinking “oah this is cooler than before isn’t it?”


#21

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.

Edit:

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:


#22

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


#23

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 !



#24

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


#25

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

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):
https://mega.nz/#!a5UkSYBK!nuDo7YZ3igkU_pm7vqINlUznDIYG5Ob52TO55A_M5RY


#26

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.
Thanks


#27

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


#28

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


#29

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.


#30

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.


#31

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 S D F G

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

addition
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)


#32

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


#33

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?


#34

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: https://forum.natron.fr/t/a-composer-as-nle)

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


#35

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?


#36

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.


#37

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.