get rid of `cells.color` and `cells.background_color` and replace with specific cells.

[braxtonmckee]

I use 'color' to change the color of octicons and buttons, mostly for purposes of indicating that they are inactive. I use 'background_color' to indicate that a line item in a tree-nav I built is selected, or to style a nav-pane.

I think we could replace these 'color' objects by giving octicon, text, and Button a formal color argument. We can replace the background_color uses with some more specific ux elements (e.g. Panel that has a selected argument, or HeaderBar and EmbeddedPanel that have some visual styling with a coherent look and feel. In general, I'd like to move most colors out of the code and make more specific UX verbs that correspond to the visual elements we actually see. It's better to have many different specific-purpose visual elements than it is to have a trillion hard-coded colors floating around in client code.

[dkrasner]

I am working on this and related styling updates in cells/components.

Is it fair to say that you want every method found in Cell._divStyle() (height, width, color etc) to be eventually removed and whatever necessary, i.e. whatever can't be properly auto-styled on the client side, included as explicit arguments in the cell class init method?

For example, Octicon('alert', color='red').

[braxtonmckee]

I think having functions for color, italic/bold/underling, etc. are reasonable to have on leaf components like text and octicon, but not on all cells. I think we should be using container components that have specific meaning everywhere else. Specifically, if you want to make a panel in the UI blue, we should have a specific cell that does that that uses CSS to pick the actual colors instead of having a 'background_color' function on the panel that you just set to blue.

On the decision of whether it's an argument or a function, I think the chained functions for styling are nice to have.

But yes, in general ultimately i'd like to get rid of the idea that 'styling' is a general property of cells, and have it only on the very small subset of leaf cells where it makes sense.

On Wed, Jul 17, 2019 at 10:31 AM dkrasner notifications@github.com wrote:

I am working on this and related styling updates in cells/components.

Is it fair to say that you want every method found in Cell._divStyle() https://github.com/APrioriInvestments/nativepython/blob/dev/object_database/web/cells/cells.py#L763 (height, width, color etc) to be eventually removed and whatever necessary, i.e. whatever can't be properly auto-styled on the client side, included as explicit arguments in the cell class init method?

For example, Octicon('alert', color='red').

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/APrioriInvestments/nativepython/issues/163?email_source=notifications&email_token=AB6OHBEJTC5WBU6BHBJQJSTP74UKXA5CNFSM4H7JUY72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2EMUBQ#issuecomment-512281094, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6OHBAI57L5G67EVU3ZX7LP74UKXANCNFSM4H7JUY7Q .

[dkrasner]

ok sorry I am going to start adding arguments to small components like Octicon so we can get closer to having no real style computations on the server side

for example, Octicon will have an api like Octicon('alert', color='red')

yes?

[braxtonmckee]

sure, that sounds good.

On Wed, Jul 17, 2019 at 11:55 AM dkrasner notifications@github.com wrote:

ok sorry I am going to start adding arguments to small components like Octicon so we can get closer to having no real style computations on the server side

for example, Octicon will have an api like Octicon('alert', color='red')

yes?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/APrioriInvestments/nativepython/issues/163?email_source=notifications&email_token=AB6OHBDYQJME6CG2QCZLJ2DP746FRA5CNFSM4H7JUY72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2E3P2Y#issuecomment-512341995, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6OHBHZ7OCYJ3P3OOPLFLDP746FRANCNFSM4H7JUY7Q .

[dkrasner]

ok sounds good. Note this will be a breaking change then, b/c the Octicon cell will now pass color only through the color arg, i.e. self._divStyle() will not be called.

[dkrasner]

Another way to approach the css properties (like background color) is to create a design spec that describes exactly what each type of cell will be.

This is exactly the purpose of a UX design spec - to create a uniform style for all types of visual objects and their displays. So we could go down this line: all buttons of this type have this style, all tables this etc etc

this way we don't have to create extra display: none/modifier cells, and ways to handle that, and the python programmer has less to think about. If at some point core design features need to be changed that can be done in a the application css file(s).

[braxtonmckee]

yeah, that's what I was thinking. Instead of 'background color', we have a cell like 'embedded panel' or 'highlighted panel' or something that lets us get the effects without specifying the styling.

On Wed, Aug 14, 2019 at 9:54 AM dkrasner notifications@github.com wrote:

Another way to approach the css properties (like background color) is to create a design spec that describes exactly what each type of cell will be.

This is exactly the purpose of a UX design spec - to create a uniform style for all types of visual objects and their displays. So we could go down this line: all buttons of this type have this style, all tables this etc etc

this way we don't have to create extra display: none/modifier cells, and ways to handle that, and the python programmer has less to think about. If at some point core design features need to be changed that can be done in a the application css file(s).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/APrioriInvestments/nativepython/issues/163?email_source=notifications&email_token=AB6OHBAG5CNSDGSJZ46BGCLQEQE7PA5CNFSM4H7JUY72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4I3UYA#issuecomment-521255520, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6OHBEETCGCCO3XQVYQQF3QEQE7PANCNFSM4H7JUY7Q .