Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard colors #274

Closed
nortikin opened this issue Jun 29, 2014 · 12 comments
Closed

Standard colors #274

nortikin opened this issue Jun 29, 2014 · 12 comments

Comments

@nortikin
Copy link
Owner

for this message:
#120 (comment)
for this dialog under commit
#272
i open issue for coloring

@nortikin
Copy link
Owner Author

in order of different color schemes, we need customization and unification of color schemes.
I use dark themes in blender, someone bright, somone vibrant.
Propose define colors with usage of layout:
https://docs.google.com/file/d/0B6KMvjWAjGiyOURiOWZNU1JhSG8/edit

@enzyme69
Copy link
Collaborator

prtscr capture_12

I also use darker coloring, but one note: I lighten the node-tree background. Overall, I am very happy with how it looks. I use Yellow for nodes that I can play with parameters with.

@nortikin
Copy link
Owner Author

Updated Blend file with proposed colors
reduced vibrations and made usual nodes list non-custom colored, other are.
maybe we should leave numbers nodes non-custom instead, because it is parameters, that user may want to make differ

@nortikin
Copy link
Owner Author

@enzyme69 what we are talking now about - is static colors, that you maybe can turn off in user preferences in future. it will be right.
and define non-default color scheme.
But when active, you will not change colors, i think except number nodes: list insert, int, float, ranges, formula etc

@nortikin
Copy link
Owner Author

also this is first def:

sv_nodes_color_type = {'basic_in':[(0, 0.5, 0.2),(0, 0.1, 0.05)], 'basic_out':[(1, 0.3, 0),(0.1, 0.05, 0)]}
def sv_nodes_color(self, type,condition):
    colors = sv_nodes_color_type[type]
    self.use_custom_color = True
    if condition:
        self.color = colors[0]
    else:
        self.color = colors[1]

it may be part of an updateNode function or i can insert this to every node. first case seems to be better

@ly29
Copy link
Collaborator

ly29 commented Jun 30, 2014

updateNode is the wrong place since that only happens on property changes.

do_update is perhaps the right place, but things will move around there soon...
A node can have at least 3 states.

  1. Not ready
  2. Ready
  3. Failure

@ly29
Copy link
Collaborator

ly29 commented Jun 30, 2014

Perhaps something like this.

def apply_sv_color(node):
    if not settings.use_sv_auto_color:
        return
    category = sv_category.get(node.bl_idname)
    if not category:
        print("Could find node category for {0}".format(node.bl_idname))
    colors = sv_colors.get(node.bl_idname)
    if colors:
        node.use_custom_color = True
        node.color = colors[node.state]
    else:
        print("No color found for category {0}".format(category)

@nortikin
Copy link
Owner Author

so, every node should have this mark or it will be separate catalog as we have init.py in nodes folder?

@nortikin
Copy link
Owner Author

some nodes as text in out not use the same scheme in work as others, than we should keep some code in node directly? i think it is not right. that happened text in out not colored now

@ly29
Copy link
Collaborator

ly29 commented Jun 30, 2014

Every node should have the state, it works like the condition in your code but is kept in the node where the node update function is responsible for setting the correct state, this is anyway needed for #152, the update system applies the correct color based on state, if the user wants sverchok to do that.

The colors dictionary should be kept controlled from settings, the category needs to be either a dict and maintain or we make a class hierarchy for sorting the nodes a bit.

@nortikin nortikin mentioned this issue Jun 30, 2014
47 tasks
@enzyme69
Copy link
Collaborator

Yes, "state" is exactly what I just mentioned on email thread to Zeffii.
Kind of a way to have better idea what is calculating and baking. Hence my
question about: is data keep updating all the time. Why is it when the
connection is broken/there is bad data, and the whole node-tree stopped
working.

@ly29
Copy link
Collaborator

ly29 commented Jul 1, 2014

Data is reset on a node tree basis on every editor(*) event, this since every update event needs to call the update function on every node anyway. The problem here is that the user interface update function is doing the actual processing of the data. Is this good? No, but it is non-trivial problem since the amount of change on a edit event is hard to tell.

(*) Edit events are anything that create socket and change links. Changing the value in a node doesn't do this. Have look at #121 for some details

@ly29 ly29 closed this as completed Nov 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants