Colour Palette update

Here then the different palette (as partly agreed). Normal objects are white, PreviewOff objects are dark and disabled objects are grey (and blurred icons).

As you will note, dark icons are difficult to read on the dark background.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Replies to This Discussion

Permalink Reply by Sameer Kumar on November 13, 2009 at 4:04pm

David,

I would like to add that components that do not preview like sliders, scalar operators etc. should be of the "preview off" color code by default instead of the "preview on". This would further enhance the visibility of "preview on" components in large definitions.

Permalink Reply by David Rutten on November 14, 2009 at 9:19am

Hi Sameer,

The colours are now stored in xml files, so if you must change them you can. However, I think I'll hold off for a bit before making this customizable. I'm worried that communication will become very difficult when everyone starts posting screenshots with -to everyone else- unreadable colour schemes.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by David Rutten on November 14, 2009 at 9:20am

When it comes to grouping, I can see having a custom coloured rectangle around all the grouped items (or some other arbitrary shape) would also work quite well.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Chris K. Palmer on November 13, 2009 at 4:33pm

Hi David,

I follow the logic of this scheme and like it.

My only comment is that I am a bit red green color blind and the "Preview Off Selected" looks like the red of a component with an error although when I look close I can see the difference. Probably not a big concern though.

I agree with Andy about keeping some top down standard for the look of components. I think there are plenty of ways with the graphic curve imports etc. to draw shapes with different colors and line styles around groups of components to organize them making no need for all kinds of custom colors.

Look forward as always to the next step while enjoying the present state,

Chris K. Palmer

Permalink Reply by Nathan Miller on November 13, 2009 at 9:11pm

Question...

This may sound cheesy... In the future would it be possible to allow users to set up "custom themes" for the grasshopper components and background... or maybe choose from a set ('Classic', Hippy, Goth... etc)?

A Grasshopper interface for any lifestyle!

Permalink Reply by Luis Fraguada on November 14, 2009 at 6:06am

It seems this would be the way to make all happy...have default colors, themes, and customizable settings. I guess the person coding it or people who like things the way they are might not like it, but as long as it does not get in the way, then it would be the way to go eventually.

Permalink Reply by Vicente Soler on November 14, 2009 at 6:19am

It would be the way to make people happy, but not necessarily the best way. It's always easy for developers to dump as much decisions as possible to the end user. Sometimes it's better if they go for what they think is best, not matter what the majority of users think. That's how you make progress (or fail miserably), i guess.

Permalink Reply by Luis Fraguada on November 14, 2009 at 6:25am

It would be the way to make people happy, but not necessarily the best way.

Def agree with you there!

Permalink Reply by Theunis du Toit on November 14, 2009 at 6:50am

Agreed, but there are additional advantages that must be considered as well. If individual and groups of components can be given their own colors it could be a handy management tool for large definitions. I tend to cluster components in groups in large definitions to be able to identify where whats happening in a large definition but being able to make different groups of components different colors would help a lot. Maybe it is not a big issue but I think it is something that will come up more and more in the future and making component's colors manipulable would kill two birds with one stone, in a sense.

Permalink Reply by David Rutten on November 14, 2009 at 9:26am

Theunis,

the colour of a component depends on so many variables at the moment that trying to make it user-definable would be very difficult.

If you want to colour-code collections of components, doesn't it make more sense to somehow have a mechanism like grouping, where a coloured border is drawn around objects that belong to a single group?

I've already often seen people put coloured TextPanels behind components that belong together. Although that messes with mouse-pick-operations, it does seem to work quite well.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Theunis du Toit on November 14, 2009 at 9:36am

Sure, it was just an idea I kind of threw out there.

Thanks for the reply.

Again, for me your latest suggestion would be good. I also liked Jacek's suggestion.

Good luck, whatever you decide.

Permalink Reply by taz on November 16, 2009 at 8:47am

Group coloring could be a useful attribute (Prior to clusters?).

As you mention whenever people underlay TextPanels as a group border it looks good, but then trying to then select component on top invariably results in inadvertently selecting the TextPanel half the time...