[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema. by lkishalmi · Pull Request #1661 · apache/netbeans

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi · 2019-11-24T21:39:59Z

This one contains a new DTD which probably have to be installed on netbeans.apache.org/dtds/ as well.
It might help for #1652 in the future.

eirikbakke · 2019-11-24T23:47:56Z

+ } else if (name.equals(E_COLORREF)) {
+ String nameAttr = attributes.getValue(A_NAME);
+ String colorAttr = attributes.getValue(A_COLOR);
+ String oldRef = colorrefs.put(nameAttr, colorAttr);


Should null-check and check validity of nameAttr/coloAttr before putting them in the map

Add a check that nameAttr is not, in fact, a valid color string. This could lead to very confusing results otherwise, e.g. redefining "ff0000" by accident. Perhaps require color references to use some special syntax, e.g. a color defined as "editorBackground" must be referenced "$editorBackground" (do colorrefs.put("$" + nameAttr, colorAttr) to achieve this). Perhaps also require the names to follow Java identifier requirements, e.g. start with Character.isJavaIdentifierStart and every subsequent character must be Character.isJavaIdentifierPart.

Null check is actually done by the parser as both name and color attributes are requested. If they are missing we got a parser exception first before we could check for null.
As of masking predefined colors, I do not see any problem with that. These color definitions is local to the file where they are defined. The whole idea is coming from my attempt to port https://github.com/morhetz/gruvbox/ to NetBeans. In order to support both light and dark mode, I'd just flip the palette definitions.
As of add a distinctive syntax when referring the color definitions. I was thinking about it as well, though I'm natural on that one. The only reason for opting that out is only that less typing makes me happy.

eirikbakke · 2019-11-24T23:58:18Z

+<!ELEMENT fontscolors ( colorref*, fontcolor* ) >
+<!ATTLIST fontscolors >
+
+<!ELEMENT colorref EMPTY >


As before, maybe call this colordef rather than colorref.

colordef is better, idea accepted! Thank you!

…exception.

neilcsmith-net · 2019-11-27T10:50:23Z

Bit tied up with other things to review properly, but +1 to the principle - great idea!

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

lkishalmi added this to the 11.3 milestone Nov 24, 2019

lkishalmi requested review from eirikbakke, geertjanw, jlahoda and neilcsmith-net November 24, 2019 21:40

eirikbakke reviewed Nov 24, 2019
View reviewed changes

lkishalmi force-pushed the NETBEANS-3440 branch from da49c24 to 21f0cdaCompare November 25, 2019 05:44

[NETBEANS-3440] Allow to define a palette for fontcolors XML Schema.
a302127

lkishalmi force-pushed the NETBEANS-3440 branch from 21f0cda to a302127Compare November 25, 2019 06:59

lkishalmi mentioned this pull request Nov 26, 2019
[NETBEANS-3440] Adding the new EditorFontsColors 1.2 DTD apache/netbeans-website#429
Merged

lkishalmi added 2 commits November 25, 2019 23:09

Lambda overrides diamonds
0e9e310

Make color parsing fail with a warning and default red instead of an …
bbcbcec
…exception.

lkishalmi merged commit 1ee3fe7 into apache:masterNov 28, 2019

Uh oh!

Conversation

lkishalmi commented Nov 24, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neilcsmith-net commented Nov 27, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

lkishalmi commented Nov 24, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neilcsmith-net commented Nov 27, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

lkishalmi commented Nov 24, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!